Web Server HTTP Dangerous Method Detection (Nessus plugin 10498) means a web server accepted PUT or DELETE requests, so a client may be able to upload or delete files over HTTP. Fix it by removing or disabling WebDAV, allowing only the methods the application needs (usually GET, POST, HEAD and OPTIONS), then retesting with curl and rescanning.
What the scanner is actually detecting
This is a remote, unauthenticated web check. It never reads configuration files; it reports how each listening web service answered. Three Tenable checks often appear together, and only the first is a vulnerability finding in its own right:
| Scanner | Finding title | ID | Severity |
|---|---|---|---|
| Nessus | Web Server HTTP Dangerous Method Detection | Plugin 10498 | High |
| Nessus | HTTP Methods Allowed (per directory) | Plugin 43111 | Info |
| Tenable Web App Scanning | Allowed HTTP Methods | Plugin 98047 | Info |
Tenable’s synopsis for 10498 is that “the remote web server allows the PUT and/or DELETE method.” Plugin 43111 instead sends OPTIONS to each directory and lists the advertised methods; Tenable notes that this output does not necessarily indicate a vulnerability. Plugin 98047 is the Web App Scanning equivalent. Always read the 10498 plugin output, because it shows which path and method succeeded.
How serious is it?
It depends on what the accepted method can do. The worst case is the one Tenable describes: PUT stores a file in a directory where the server executes scripts (ASP, JSP, PHP), and the upload then runs with the web server’s privileges. Tenable also lists a public Metasploit module for IIS WebDAV write access. DELETE lets someone remove content. Even without script execution, a writable web root can host phishing pages under your domain or fill the disk.
Tomcat shows how this plays out in practice: CVE-2017-12617 (JSP upload leading to code execution) and CVE-2025-24813 (partial PUT) both required writes to be enabled on the DefaultServlet, which is off by default.
That said, many hits are not writable web roots: REST APIs legitimately accept PUT and DELETE behind authorization, and some applications answer 200 to any method without storing anything. Confirm first, but treat a confirmed anonymous write as urgent.
How to confirm it on the host
Start with what the server advertises, then test whether a write actually lands. Only test systems you are authorized to test, use a unique file name, and never send DELETE to a path you did not just create.
# Advertised methods
curl -i -X OPTIONS https://host.example.com/
nmap -p 80,443 --script http-methods host.example.com
# Does PUT really write?
curl -i -X PUT --data 'method-test' https://host.example.com/method-test-7f3a.txt
curl -i https://host.example.com/method-test-7f3a.txt
# Clean up only the file you created
curl -i -X DELETE https://host.example.com/method-test-7f3a.txtA 201 or 204 on the PUT followed by your text on the GET is a confirmed finding. A 405, 403, 401 or (on IIS) 404 means the write was refused. Next, find the component responsible:
# IIS (Windows Server, elevated PowerShell)
Get-WindowsFeature Web-DAV-Publishing
C:WindowsSystem32inetsrvappcmd.exe list config "Default Web Site" -section:system.webServer/webdav/authoring
C:WindowsSystem32inetsrvappcmd.exe list config "Default Web Site" -section:system.webServer/security/requestFiltering
# Apache (apache2ctl on Debian and Ubuntu)
apachectl -M | grep -i dav
grep -RniE '^s*Davs+On' /etc/httpd/ /etc/apache2/ 2>/dev/null
# nginx
sudo nginx -T 2>/dev/null | grep -nE 'dav_methods|limit_except'
# Tomcat
grep -n -A1 'readonly' "$CATALINA_BASE/conf/web.xml" "$CATALINA_BASE"/webapps/*/WEB-INF/*.xmlHow to fix it
The principle, which Tenable also recommends for plugin 98047: permit only the methods the application needs. Remove WebDAV first wherever nobody uses it, since it brings extra write methods (MKCOL, COPY, MOVE).
IIS
WebDAV Publishing is an optional role service under Common HTTP Features and is not part of a default IIS install. If nothing publishes over WebDAV, remove it from an elevated PowerShell prompt and restart if prompted:
Uninstall-WindowsFeature Web-DAV-Publishing # Windows Server
DISM /Online /Disable-Feature /FeatureName:IIS-WebDAV # Windows client editionsIf another site on the same server still needs WebDAV, disable authoring only for the flagged site. This setting lives at site level in applicationHost.config:
C:WindowsSystem32inetsrvappcmd.exe set config "Default Web Site" -section:system.webServer/webdav/authoring /enabled:"False" /commit:apphostThen add Request Filtering rules. The minimal change denies PUT and DELETE in the site’s web.config:
<system.webServer>
<security>
<requestFiltering>
<verbs>
<add verb="PUT" allowed="false" />
<add verb="DELETE" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>The stronger option is an allow list. With allowUnlisted="false", IIS processes only the verbs you list, so every verb the site needs must be present:
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="HEAD" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="OPTIONS" allowed="true" />
</verbs>Do not set applyToWebDAV="false": Microsoft’s own sample uses that value to let WebDAV requests bypass the verb rules. Denied verbs return 404 and are logged with substatus 404.6 (Verb Denied).
Apache httpd
Stock Apache has no handler that stores PUT uploads. That comes from mod_dav (switched on with Dav On inside a container) or from an application script. Remove every Dav On you do not need, and unload the modules if nothing uses them: on Debian and Ubuntu run sudo a2dismod dav_fs and then sudo a2dismod dav; on the RHEL family comment out the dav LoadModule lines under /etc/httpd/conf.modules.d/.
To restrict methods, the Apache 2.4 Require method provider is the clearest option. Use it in place of Require all granted in the <Directory> or <Location> that serves the site:
<Directory "/var/www/html">
Require method GET POST OPTIONS
</Directory>Per the Apache documentation, this admits GET, HEAD, POST and OPTIONS and refuses everything else, normally with 403. Many hardening guides use the older <LimitExcept GET POST HEAD> Require all denied </LimitExcept> form instead. Apache documents that the first Require to succeed authorizes the request, so a Require all granted in the same block can still let PUT through; if you keep that form, prove it with curl. Neither form covers TRACE, which needs TraceEnable Off.
sudo apachectl configtest && sudo systemctl reload httpd # RHEL family
sudo apache2ctl configtest && sudo systemctl reload apache2 # Debian familynginx
Out of the box, nginx handles PUT and DELETE only through ngx_http_dav_module, which is not built by default and whose dav_methods directive defaults to off. Remove any dav_methods line you do not need. Where a location proxies to an application that might accept writes, block them at the edge with limit_except, which is valid only inside a location block. Allowing GET also allows HEAD:
location / {
limit_except GET POST {
deny all;
}
proxy_pass http://app_backend;
}Add OPTIONS to the list if browsers send CORS preflight requests to that location. Blocked methods receive 403. Apply with sudo nginx -t && sudo systemctl reload nginx.
Apache Tomcat
The DefaultServlet readonly init parameter defaults to true, which rejects PUT and DELETE. A hit on a Tomcat port usually means someone set it to false in $CATALINA_BASE/conf/web.xml, or redefined the DefaultServlet in an application’s WEB-INF/web.xml or WEB-INF/tomcat-web.xml. Remove the override or set it back, then restart Tomcat:
<init-param>
<param-name>readonly</param-name>
<param-value>true</param-value>
</init-param>Load balancers, CDNs and WAFs
If the origin refuses writes but the scan still reports them, something in front of it answered. Check that device’s method policy, and read how a WAF changes what a web scan actually sees before deciding which result to trust.
How to verify the fix and rescan
- Repeat the PUT test from outside the server, against every hostname and port in the finding. Expect 405, 403 or (IIS) 404, and a 404 when you GET the test path.
- Test through the same path the scanner uses. If it scanned a public VIP, test the VIP, not a single backend node.
- Do not judge by the OPTIONS response alone. An
Allowheader can still list a method the server refuses, which is why plugin 43111 may keep listing it. - Rescan with the same policy. In Nessus you can limit the rescan to plugin 10498 on the affected hosts.
What can break and how to roll back
- WebDAV users: mapped web folders and publishing tools that upload through WebDAV stop working. Ask the site owner first.
- REST APIs: a site-wide allow list blocks legitimate PUT, PATCH and DELETE routes. Scope the rule to static content paths, or allow those verbs only on API paths where the application enforces authorization.
- CORS: browsers send OPTIONS preflight requests for many cross-origin calls, so keep OPTIONS allowed wherever that happens.
- Health checks: monitors that use HEAD fail on IIS if HEAD is missing from the allow list.
Back up before changing anything. On IIS, appcmd.exe add backup BeforeVerbs saves applicationHost.config (copy web.config files separately) and appcmd.exe restore backup "BeforeVerbs" restores it, briefly stopping IIS; reinstall WebDAV with Install-WindowsFeature Web-DAV-Publishing. On Apache, restore Require all granted and Dav On (re-enable modules with a2enmod), then run configtest and reload. On nginx, remove the limit_except block and reload. On Tomcat, restore the previous web.xml and restart.
Common false positive reasons
- Catch-all responses: the application returns 200 for any method but stores nothing. A 404 on GET of the test path proves it; keep that evidence.
- Intended API behavior: a route designed to accept PUT or DELETE with its own authorization is not a writable document root.
- Informational plugins read as vulnerabilities: 43111 and 98047 report advertised or allowed methods, not successful writes.
- Wrong device: the response came from a load balancer, CDN or WAF rather than the server you changed.
- Stale results: the report predates the change, or a node was out of the pool.
FAQ
Should I disable OPTIONS too?
Usually not. OPTIONS changes nothing on the server, and browsers need it for CORS preflight. Plugin 43111 uses it to list methods, which is informational.
Why does IIS return 404 instead of 405 after the fix?
That is how Request Filtering reports a denied verb. The IIS log shows 404.6, and the write is refused.
Our REST API needs PUT and DELETE. Do we have to remove them?
No. Keep them on the API routes, require authorization for every write, and make sure no method writes files into a web-served directory.
Is blocking PUT and DELETE enough if WebDAV stays on?
Not by itself. WebDAV adds other write methods such as MKCOL, COPY and MOVE. Remove WebDAV or use an allow list so unlisted methods are refused.
Tracking this finding across many hosts
This check fires per host and per port, so a web farm can generate many rows. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results arrive as an uploaded .nessus export) and merges duplicates within each scanner. Nessus findings such as plugin 10498 can be retested individually after the change, and host-specific remediation scripts drafted by its AI run through its agents on Windows and Linux only after a human approves them.