HIGH 7.2

CVE-2026-48895: Apache APISIX Open Redirect Vulnerability (v3.0.0–3.16.0)

Apache APISIX versions 3.0.0 through 3.16.0 contain an open-redirect vulnerability that allows attackers to manipulate HTTP client headers and redirect users to untrusted websites. This attack could potentially expose session tokens or other sensitive authentication data. The issue affects the API gateway's request handling and requires upgrading to version 3.17.0 or later to remediate.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.2 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Weaknesses (CWE)
CWE-601
Affected products
1 configuration(s)
Published / Modified
2026-06-19 / 2026-06-23

NVD description (verbatim)

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache APISIX. The attacker could manipulate some client headers to perform an open-redirect, to potentially expose the session token. This issue affects Apache APISIX: from 3.0.0 through 3.16.0. Users are recommended to upgrade to version 3.17.0, which fixes the issue.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability (CWE-601) exists in APISIX's URL redirection logic, where insufficient validation of client-controlled headers permits an attacker to craft requests that redirect users to arbitrary external sites. The attack requires no authentication, can be triggered over the network without special conditions, and impacts the integrity and confidentiality of user sessions. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N) reflects network-exploitable, low-complexity exploitation with cross-boundary scope impact.

Business impact

An open-redirect vulnerability in an API gateway creates a high-profile attack surface. Threat actors can use APISIX instances as pivot points to steal authentication credentials, capture session tokens, or conduct phishing attacks that appear to originate from a trusted organization's infrastructure. For enterprises running APISIX in production, this exposes both direct users and downstream API consumers to credential theft and session hijacking. Reputational damage and compliance violations (e.g., GDPR incident notification) are secondary risks if user data is exfiltrated via this vector.

Affected systems

Apache APISIX versions 3.0.0 through 3.16.0 are vulnerable. Organizations running APISIX as an API gateway, reverse proxy, or service mesh control plane with these versions should inventory their deployments immediately. Version 3.17.0 and later versions contain the fix. The vulnerability does not affect APISIX versions prior to 3.0.0.

Exploitability

This vulnerability is straightforward to exploit and requires no authentication or special preconditions. An attacker can trigger the open-redirect by sending a specially crafted request with manipulated headers to any APISIX instance exposed on the network. User interaction (e.g., clicking a malicious link) may be needed to harvest credentials, but the vulnerability itself is not dependent on user action—the redirect mechanism is automatically triggered by APISIX. The attack is network-accessible from any vantage point, making it remotely exploitable at scale.

Remediation

Upgrade Apache APISIX to version 3.17.0 or later. This is the definitive fix. Organizations unable to upgrade immediately should review network exposure of APISIX instances, restrict external access where possible, and monitor redirect logs for suspicious patterns. Consider implementing a WAF rule to detect or block suspicious client headers that could trigger redirects, though this is a temporary control pending patching.

Patch guidance

1. Verify your current APISIX version (apisix -v or check your deployment manifests). 2. Review the official Apache APISIX release notes for version 3.17.0 to understand any breaking changes or new dependencies. 3. Test the upgrade in a non-production environment first, particularly if you have custom plugins or middleware that may interact with request headers. 4. Plan a rolling or blue-green deployment to minimize downtime. 5. After upgrading, validate that client redirect functionality works as intended and that security monitoring continues to operate normally.

Detection guidance

Monitor APISIX access and error logs for unusual redirect responses (HTTP 301/302) sent to external domains. Examine client headers (particularly Host, Referer, X-Forwarded-For, and custom headers) in requests that precede redirect responses. Use SIEM correlation rules to identify patterns where APISIX is redirecting to known malicious or non-organization domains. Also monitor for authentication logs showing session tokens or cookies being accessed from unexpected geographies or IP ranges, which may indicate post-compromise activity from harvested credentials.

Why prioritize this

This vulnerability rates HIGH (CVSS 7.2) due to network-exploitable access, low attack complexity, and potential exposure of session tokens—a direct path to account takeover. Unlike vulnerabilities requiring user interaction or authentication, this can be attacked without friction. It affects a critical infrastructure component (API gateway) that typically sits in a high-trust network position, amplifying the business impact. Immediate patching is strongly advised for any organization running affected versions in production.

Risk score, explained

The CVSS 3.1 score of 7.2 reflects: (1) Attack Vector: Network—remotely exploitable with no special access; (2) Attack Complexity: Low—no special conditions or timing required; (3) Privileges Required: None—unauthenticated exploitation is possible; (4) User Interaction: None—the redirect is automatic, though credential harvesting may benefit from social engineering; (5) Scope: Changed—the vulnerability affects API consumers and end users beyond the direct APISIX system; (6) Confidentiality & Integrity: Low impact each—session tokens and redirect behavior are compromised, but not the entire system. Availability is not impacted. The 'HIGH' severity bucket warrants immediate executive attention and patch prioritization.

Frequently asked questions

Can this vulnerability be exploited if APISIX is only accessible on an internal network?

Yes. While internal-only deployment reduces exposure, an attacker with any network access to APISIX—whether via compromised internal hosts, insider threats, or VPN—can trigger the redirect and potentially exfiltrate tokens. However, internal deployment does lower the overall risk compared to internet-facing instances. Still, patching is essential.

Does this affect APISIX deployments in Kubernetes or containerized environments?

Yes. The vulnerability exists at the application level in APISIX itself, regardless of whether it runs as a container, virtual machine, or bare metal. Deployment architecture does not mitigate the flaw; upgrading APISIX to 3.17.0 is required.

What if we cannot upgrade immediately—are there interim mitigations?

Implement network-level restrictions to limit who can reach APISIX from external networks. Deploy a WAF or API gateway upstream of APISIX to inspect and block requests with suspicious header patterns. Monitor logs aggressively for redirect anomalies. However, these are temporary measures. Upgrading to 3.17.0 should be scheduled as high priority within your change management process.

Is there active exploitation of this vulnerability in the wild?

As of the publication date (2026-06-19), this vulnerability has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the ease of exploitation and potential for credential theft mean organizations should treat this as urgent regardless of current threat intelligence signals.

This analysis is based on official CVE data and Apache APISIX advisories as of 2026-06-23. Patch version numbers, CVSS scores, and vendor recommendations are sourced directly from the published CVE record and should be verified against the official Apache APISIX security advisory before implementation. This document does not constitute legal or compliance advice. Organizations should conduct their own risk assessment and consult with their security and legal teams regarding remediation timelines. No exploit code or detailed attack methodology is provided; exploitation details are intentionally limited to prevent weaponization. Source: NVD (public-domain), retrieved 2026-07-27. Analysis generated by SEC.co (claude-haiku-4-5).