The vendor has published a fix. Version details are below where the sources state them.
Steps
Written by AI from the record
Check your OpenResty version and confirm whether you use ngx.req.get_uri_args or ngx.req.get_post_args in your Lua apps or routing logic.
If your version is OpenResty through 1.13.6.1, plan an upgrade to a version where it is fixed.
Upgrade OpenResty to the fixed release (fixed in 1.13.6.1 per vendor).
If you rely on a WAF/X-WAF that inspects request parameters, test with requests that include more than 100 parameters and verify protections still trigger.
In OpenResty through 1.13.6.1, URI parameters are obtained using the ngx.req.get_uri_args and ngx.req.get_post_args functions that ignore parameters beyond the hundredth one, which might allow remote attackers to bypass intended access restrictions or interfere with certain Web Application Firewall (ngx_lua_waf or X-WAF) products. NOTE: the vendor has reported that 100 parameters is an intentional default setting, but is adjustable within the API. The vendor's position is that a security-relevant misuse of the API by a WAF product is a vulnerability in the WAF product, not a vulnerability in OpenResty
In plain language
Written by AI from the record
OpenResty through 1.13.6.1 can mishandle very large numbers of request parameters, which may let attackers bypass some protections; most small businesses should patch if they use OpenResty in front of public web traffic.
CVE-2018-9230 is an issue in OpenResty (through 1.13.6.1) where ngx.req.get_uri_args / ngx.req.get_post_args ignore parameters after the 100th, which can allow crafted requests to bypass or interfere with access-control or WAF logic that depends on those parameters; public proof-of-concept exists, but it’s not confirmed via CISA KEV.
If you're affected
Bypass web access restrictions
WAF protection interference
Potential data exposure
Service disruption risk
What is it
Think of OpenResty as a mailroom that reads addresses written on envelopes (request parameters). With this bug, if someone writes more than 100 addresses in one envelope, the extra ones may be ignored. If your protections (like firewall rules or access checks) rely on seeing those extra addresses, an attacker may be able to slip through or confuse the protection.
Who is affected
This matters if you run OpenResty (a web server with Lua scripting) and your public site accepts many query/body parameters. It’s most relevant when your security controls or WAF rules depend on parameters that would fall past the 100th one. Practical risk exists when an attacker can reach your OpenResty-powered site over the network and can send requests with more than 100 parameters (for example, by targeting public endpoints).
How urgent is it
This has a public proof-of-concept and a very high severity score, but it’s not confirmed as exploited in the wild via CISA KEV. Treat it as a near-term patch need: upgrade if you’re running OpenResty at or below 1.13.6.1, especially if you have any WAF/access-control logic that inspects many request parameters. Mark it Amber because real-world impact depends on whether your setup uses parameter-based security checks and whether attackers can reach the affected endpoints.
What to do — in detail
Confirm exposure
Identify your OpenResty version (from your server’s package/version info or runtime banner) and compare it to “through 1.13.6.1.”
Review your Lua usage:
Search your Lua code and Nginx/OpenResty config for calls to ngx.req.get_uri_args and ngx.req.get_post_args.
Check if your own access checks, routing decisions, or security logic depends on counting/iterating request parameters.
If you use a WAF/X-WAF that integrates with Lua/Nginx or inspects the same parameters, note how it processes request arguments.
Upgrade / remediation
Upgrade OpenResty to the fixed state referenced by the vendor: fixed in 1.13.6.1.
If you are already on a version at/above that fixed release, confirm you are not actually running an older build.
After upgrade, retest your security controls:
Send a test request to a representative endpoint with more than 100 URI parameters and (if applicable) more than 100 POST parameters.
Verify that expected protections still trigger (login checks, allow/deny rules, WAF detections).
Workaround (if you cannot patch immediately)
If your OpenResty configuration/API usage allows adjustment of how many parameters are processed, reduce reliance on parameters beyond the first 100 for security decisions.
As a compensating control, consider adding validation rules that reject requests with unusually large parameter counts to prevent attackers from using parameter count tricks.
What to monitor
Watch access logs and WAF logs for unusual requests with very large numbers of parameters (especially repeated attempts) and confirm that detections still occur post-upgrade.
Timing note
CISA KEV is not listed for this CVE, so there is no mandated CISA-only due date from the findings. Use the upgrade window you already follow for security fixes, prioritizing public-facing deployments and any setup that uses parameter-based security enforcement.
Technical context
Severity is extremely high (CVSS 9.8 reported), but exploitation is not confirmed via CISA KEV. The weakness is related to improper handling of request input (CWE-89—improper neutralization/handling of special elements), specifically an argument-parsing limit in OpenResty where ngx.req.get_uri_args / ngx.req.get_post_args ignore parameters beyond the 100th.
Attack vector/mechanism: a remote attacker crafts requests containing more than 100 parameters so that security-relevant logic that depends on complete parameter visibility may be bypassed or disrupted. This is especially relevant when an integrated WAF (or similar access-control logic) assumes it will receive/see all parameters.
Exploitation maturity: there is a public proof-of-concept. No KEV entry indicates confirmed widespread exploitation is not established in the provided findings.
Note on vendor context: the vendor indicates the 100-parameter behavior is an intentional default and may be adjustable via the API; they also characterize security-relevant misuse by a WAF product as a WAF issue rather than an OpenResty flaw. Regardless, the observable behavior remains that parameters after the 100th are ignored by these API calls through 1.13.6.1.
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
