First off, thanks for the PR.

Some comments - the tid (the first field) is the same on each line which would cause it to fail validation.

The tests itself seems to match response code == 500 && code != 404. This could create some false positives. Does the server return anything unique with the 500? (Hoping we get something useful back.)

Thanks for commenting!

I copied the duplicated tid from 007166, I thought it was supposed to be duplicated if it was for the same vulnerability. I can fix that.

Your second question is a little harder. Is it possible to send in POST data?

Each item should have a unique; it's a bit of a pain, but it made sense when Nikto first came out...

You can have POST requests, the format of a test is:
Test-ID, OSVDB-ID, Tuning Type, URI, HTTP Method, Match 1, Match 1 Or, Match1 And, Fail 1, Fail 2, Summary, HTTP Data, Headers

So if you set HTTP Method to POST and set HTTP Data to the contents. Content-Length etc should be worked out automagically for you.

OK, I'm on it.

@tautology0 what would make sense now for test IDs? :)

Jumping in, but: I think it makes sense now. I just noticed that there are other tests that share the same tid and I tried to follow that pattern.

I'll have an edited pull request tomorrow.

Those duplicates were a mistake--I just corrected them (a6e3d7f). The next available test ID now is:
007182

Thanks & sorry for the confusion!

OK, I am testing my new changes, if everything goes well I'll have an edited pull request today.

You can run with option -dbcheck to validate there are no duplicate IDs and other syntax issues (FYI there is currently one reported in a plugin but I think it needs an exception).

I realize that no one is in a rush, but it was harder than I thought to find a distinctive response string that could be used to weed out false positives. I'm working on it, and will update ASAP.

Alright, the answer is that if you get a 404 you aren't vulnerable, and if you get a 500 you are. Doesn't matter what payload you send in.

How would you like to represent that in the tests?

I discovered that if you perform a GET on the endpoints the vulnerable servers will return some strings that can be confirmed. They are a 200 response code. Also renumbered. Not sure what the conflicts are.

The conflict was a test which was submitted just before yours. I've resolved and, I think, merged. Thanks for submitting & taking the time to understand how they work!

Thank you very much. I've used Nikto for years; it's a pleasure to finally contribute. I have a list of other tests I'll add in here in the next couple of months.