CVE-2026-54290

What it actually does

The vulnerability is an unsafe CORS behavior in Hono versions prior to 4.12.25. When the CORS middleware is configured with credentials: true and no explicit origin allowlist, it reflects the inbound Origin header and also returns Access-Control-Allow-Credentials: true. That combination allows arbitrary external websites to issue credentialed browser requests to the affected application and read the responses if a victim is already authenticated. Technically, this can expose sensitive data from cookie-authenticated APIs and may allow limited state-changing actions depending on the affected endpoints, HTTP methods, CSRF protections, and SameSite cookie settings.

Why it matters to the business

Applications using affected Hono CORS middleware settings may unintentionally expose authenticated user data to any website a logged-in user visits. The main business risk is confidentiality loss from sensitive API responses, with possible account or transaction manipulation where authenticated endpoints accept cross-origin state-changing requests. Although this is not listed in CISA KEV and current EPSS is low, exploitation is simple once an attacker can lure a logged-in user to a malicious page, so internet-facing applications using cookie-based authentication should treat remediation as important.

How an attack unfolds

An attacker first identifies an application built with a vulnerable Hono version and CORS middleware configured with credentials: true while relying on the default wildcard origin behavior. The attacker then hosts a malicious webpage containing JavaScript that sends fetch or XMLHttpRequest calls to the target application with credentials included. When a logged-in victim visits the malicious page, the browser attaches the victim’s cookies to the cross-origin request. The vulnerable server reflects the attacker-controlled Origin value and returns Access-Control-Allow-Credentials: true, causing the browser to allow the malicious page to read the authenticated response. The attacker can then exfiltrate API data visible to the victim and, where endpoints permit, attempt authenticated actions using the victim’s session.

How to fix it

Upgrade Hono to version 4.12.25 or later. In addition, review all CORS middleware configuration and avoid using credentials: true with wildcard or reflected origins. Configure an explicit allowlist of trusted origins, and reject or omit CORS headers for untrusted origins. Prefer restrictive defaults: specify exact schemes, hosts, and ports; avoid broad subdomain wildcards unless necessary; and ensure Access-Control-Allow-Credentials is only returned for approved origins. Strengthen session protections by using SameSite=Lax or SameSite=Strict cookies where compatible, requiring CSRF tokens for state-changing requests, and avoiding sensitive data exposure through endpoints that do not need browser-based cross-origin access.

How to confirm the fix worked

Confirm the application dependency tree uses Hono 4.12.25 or later. Review application code for CORS middleware declarations that set credentials: true without an explicit origin allowlist. Test externally with a controlled Origin header such as https://cors-validation.example and an authenticated session: vulnerable behavior is indicated if the response includes Access-Control-Allow-Origin reflecting that arbitrary origin and Access-Control-Allow-Credentials: true. After remediation, untrusted origins should either receive no Access-Control-Allow-Origin header or should not receive Access-Control-Allow-Credentials: true. Also verify that trusted origins still function as intended and that state-changing endpoints enforce CSRF protections.

Typical attack path

1. Identify a Hono-based application using a vulnerable version prior to 4.12.25.
2. Confirm the application has CORS enabled with credentials: true and no explicit origin allowlist.
3. Host a malicious webpage under an attacker-controlled origin.
4. Lure or redirect an authenticated user of the target application to the malicious webpage.
5. Use browser JavaScript to send credentialed cross-origin requests to the target application.
6. Rely on the vulnerable CORS response reflecting the malicious Origin and allowing credentials.
7. Read authenticated API responses in the attacker-controlled page and exfiltrate sensitive data or attempt permitted state-changing requests.

How to detect it

Investigate web access logs, reverse proxy logs, CDN/WAF logs, and application logs for authenticated requests containing unexpected or untrusted Origin headers. Focus on requests where the response included Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin matching the inbound Origin rather than a known trusted origin. Look for sensitive API endpoints being accessed from unusual origins, especially sequences where the same user session or source IP performs normal activity and then sudden API calls with an unfamiliar Origin. Browser-based exploitation may not produce malware artifacts on the server; evidence is usually in HTTP request and response metadata. If response headers are not logged, reproduce current behavior and review historical request logs for Origin values from domains not associated with the application. Pay special attention to successful 200-series responses to authenticated endpoints with cookies present and anomalous Origin values. There are no public named threat actors or known exploitation campaigns associated with this vulnerability based on the provided data.

• Access-Control-Allow-Credentials: true
• Access-Control-Allow-Origin: https://
• Origin: https://
• credentials: true
• cors(
• @hono/cors

What your security team should do

• Inventory Hono applications and prioritize internet-facing services that use cookie-based authentication or expose sensitive user data.
• Upgrade Hono to 4.12.25 or later across affected applications and rebuild/redeploy dependent services.
• Search code repositories for CORS middleware configurations using credentials: true without a strict origin allowlist.
• Add automated tests or CI checks that fail builds when credentialed CORS is configured with wildcard or reflected origins.
• Review session cookie settings and enforce SameSite protections where business functionality allows.
• Ensure state-changing endpoints require CSRF defenses independent of CORS controls.
• Monitor access logs for unusual cross-origin request patterns, especially requests with unexpected Origin headers followed by successful authenticated responses.