Authentication bypass in Apache Software Foundation's Apache APISIX jwe-decrypt plugin

Improper Validation of Integrity Check Value vulnerability in Apache APISIX. The jwe-decrypt plugin under default configuration is vulnerable to authentication bypass. This issue affects Apache APISIX: from 3.8.0 through 3.16.0. Users are recommended to upgrade to version 3.17.0, which fixes the issue.

• Apache APISIX is affected from 3.8.0 through 3.16.0, using semver. The affected data sets default_status to unaffected for versions outside the listed affected range.
• Apache's advisory recommends upgrading to 3.17.0 and identifies that version as fixing the issue.
• The available evidence does not independently verify the status of every other release branch outside the stated affected range and named fixed release.

This is a CWE-354 weakness in which an integrity check value is not validated correctly before an authentication decision is made. The affected component is the jwe-decrypt plugin when used under the default configuration. Network-supplied input may influence the authentication decision and lead to an authentication bypass; the available evidence does not describe the exact input format or code path. The supplied scoring facts characterize the issue as network-reachable, low complexity, requiring no prior privileges and no user interaction. Actual reachability depends on the deployment and on how the plugin is used.

• Reachability: The issue can be reached over the network. An attacker does not need prior privileges or user interaction, and the supplied scoring facts describe low attack complexity.
• Precondition: Apache APISIX must use the jwe-decrypt plugin under the default configuration. Additional deployment conditions are not documented.
• Status: The record does not identify a public exploit, named campaign, or observed exploitation evidence. This does not prove that exploitation has not occurred; it means the available evidence does not establish it.

The weakness could allow a remote attacker to cross an authentication boundary without valid credentials. This may provide access to protected API routes or permit unauthorized downstream operations, but the actual privilege level and scope depend on each route and upstream authorization policy. The record does not establish a data breach, an availability impact, a particular tenant, or a specific privilege scope. Because no user interaction is required, instances that accept untrusted network traffic should receive priority for review.

Successful exploitation could allow an unauthenticated remote party to pass an authentication decision enforced by jwe-decrypt. Depending on route and upstream policy, this could expose protected API operations or permit unauthorized actions. The record does not establish access to specific data, a particular tenant boundary, or an availability impact, so the business consequences must be assessed per deployment.

1. Upgrade Apache APISIX to exactly 3.17.0, which Apache identifies as fixing the issue.
2. Before and after the upgrade, inventory instances using jwe-decrypt, verify the version actually deployed, and test authentication flows that depend on the plugin.
3. If an immediate upgrade is not possible, do not treat a general configuration change as a confirmed fix. The record provides no product-specific workaround; any temporary control should be tested as compensating protection.
4. After remediation, review access and authentication logs for unusual activity. The absence of log evidence does not prove that unauthorized access did not occur.

1. Inventory all running Apache APISIX instances and identify deployments using the jwe-decrypt plugin.
2. Review the plugin configuration and list the routes or services that rely on it for authentication decisions.
3. Review access and authentication logs for unusual successful requests to routes that should require authentication. This is a precautionary review, not a vendor-confirmed IOC.
4. Compare deployed instances with the affected and fixed version boundaries recorded in affected_summary and remediation.
5. Do not treat the absence of suspicious log events as proof of safety, because the record does not provide a specific log signature or indicator.