CVE-2024-26331

What it actually does

The flaw is an authentication bypass caused by trusting a client-controlled cookie value as proof of authorization without cryptographically binding that value to a server-side session, authenticated identity, or session identifier. A remote unauthenticated attacker can modify or forge the relevant cookie to an expected value and gain access to protected application functionality. The CVSS vector indicates network exploitation, low complexity, no required privileges, and no user interaction, with primary impact to confidentiality: attackers may read protected reports, application data, or administrative content that should require authentication.

Why it matters to the business

Successful exploitation can allow unauthorized users to view sensitive information exposed through the affected application without valid credentials. Because exploitation is simple, remotely reachable, and assessed as weaponized with a high EPSS probability, internet-facing deployments should be treated as high priority even though it is not currently listed in CISA KEV and is not known from the supplied data to be used in ransomware campaigns. Organizations relying on the affected software for report delivery, challenge platforms, or internal data access may face data exposure, compliance impact, and loss of trust if protected content is accessed without authorization.

How an attack unfolds

An attacker first identifies a reachable instance of the affected application and determines that access to protected functionality is controlled by a cookie value. Instead of authenticating normally, the attacker modifies the cookie in a browser developer console, interception proxy, script, or custom HTTP client so that it contains the value expected by the server. Because the server checks the cookie value but does not tie it to a valid authenticated session or server-side state, the forged request is accepted as authorized. The attacker can then browse protected endpoints and retrieve information available to the impersonated or bypassed authorization context. If administrative or sensitive report views are protected only by this mechanism, the attacker may repeatedly enumerate and download confidential content without creating normal login artifacts.

How to fix it

Upgrade affected deployments to a fixed release or commit. For the supplied affected package metadata, nakiami/mellivora should be updated to commit e0b6965f8dde608a3d2621617c05695eb406cbb9 or a later version containing that fix. For ReCrystallize Server deployments matching the described issue, upgrade to a vendor-fixed version if available and verify that authorization is enforced through server-side session state rather than a standalone client-controlled cookie. As compensating controls until patching is complete, restrict network access to trusted users, place the application behind strong upstream authentication, invalidate existing sessions and cookies after upgrade, disable unauthenticated access to sensitive report endpoints, and ensure cookies are signed, tamper-resistant, scoped appropriately, marked HttpOnly and Secure, and validated against server-side session records.

How to confirm the fix worked

Confirm the deployed version or source revision includes the fixed commit e0b6965f8dde608a3d2621617c05695eb406cbb9 or a later vendor-approved fix. Perform a negative authorization test: start with a clean browser session or HTTP client with no valid login, set or modify the relevant authorization cookie, and verify that protected endpoints still return an authentication challenge or access-denied response. Confirm that authorization decisions are made using server-side session records and that changing client-side cookie values alone cannot elevate access. Review reverse proxy, web server, and application logs before and after patching to verify that requests with malformed, unexpected, or unauthenticated cookies are rejected. Re-run authenticated and unauthenticated regression tests for report viewing, administrative pages, and any endpoints that previously depended on cookie-only authorization.

Typical attack path

1. Discover an exposed affected application through scanning, search indexing, or reconnaissance.
2. Request protected pages and observe the authentication or authorization cookie behavior.
3. Modify or forge the relevant cookie to contain a value accepted by the server.
4. Replay requests to protected endpoints with the forged cookie and no valid authenticated session.
5. Enumerate accessible reports, pages, files, or administrative views.
6. Download or exfiltrate sensitive information available through the bypassed authorization boundary.

How to detect it

Investigate web server, reverse proxy, WAF, and application logs for signs that protected pages were accessed without a preceding successful login or valid session creation event. Focus on requests where a cookie associated with authorization is present but no normal session cookie, session identifier, or authentication event exists for the same source IP, user agent, and time window. Look for repeated 200 responses to protected report, administrative, export, download, or dashboard endpoints from unauthenticated clients, especially after earlier 401, 403, or redirect-to-login responses. Review logs for abnormal cookie manipulation patterns such as changing cookie values across consecutive requests, unusually short cookie values, predictable boolean or role-like values, missing companion session cookies, or cookies supplied by scripts and command-line clients. Correlate access with user-agent anomalies, high request rates, enumeration of report IDs or object IDs, and geographic or ASN changes. If the application records session validation failures or authorization decisions, search for accepted authorization decisions where the session lookup failed or was absent. Because no specific cookie name or exploit string is provided in the source data, detection should be behavior-based and application-specific rather than relying solely on static indicators.

What your security team should do

• Prioritize remediation for any internet-facing or partner-accessible deployment because exploitation is low-complexity, unauthenticated, and weaponized, with EPSS approximately 0.51.
• Upgrade affected nakiami/mellivora code to commit e0b6965f8dde608a3d2621617c05695eb406cbb9 or later, and verify any ReCrystallize Server 5.10.0.0 exposure against vendor guidance.
• Place the application behind strong centralized authentication or network allowlisting until patching is verified.
• Invalidate existing cookies and sessions after remediation to remove any previously forged or stale authorization state.
• Search historical access logs for protected resources accessed without a corresponding successful login event or valid session creation event.
• Add detections for requests to sensitive endpoints that contain authorization cookies but lack a server-side session identifier or prior authentication flow.
• Review application code and configuration for any other authorization checks that trust unsigned or unbound client-side cookie values.
• If sensitive data may have been exposed, perform data access review, notify relevant stakeholders, and follow incident response procedures.