CVE-2024-1902

7.5 HIGH

📋 TL;DR

This vulnerability allows removed users to modify organization names in lunary-ai/lunary by reusing old session tokens. Attackers can exploit this authorization flaw to make unauthorized changes to organizations they no longer belong to. All organizations using vulnerable versions of lunary-ai/lunary are affected.

💻 Affected Systems

Products:
  • lunary-ai/lunary
Versions: Versions before commit d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2
Operating Systems: All
Default Config Vulnerable: ⚠️ Yes
Notes: Affects all deployments where organization management features are enabled.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Malicious former users could rename critical organizations, causing operational disruption, confusion, and potential data access issues for legitimate users.

🟠

Likely Case

Disgruntled former employees or users could rename organizations out of spite, requiring administrative cleanup and causing temporary confusion.

🟢

If Mitigated

With proper session invalidation and authorization checks, only current organization members can modify organization settings.

🌐 Internet-Facing: HIGH
🏢 Internal Only: MEDIUM

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: LIKELY
Unauthenticated Exploit: ✅ No
Complexity: LOW

Exploitation requires a valid but outdated authorization token from a previously authorized user.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Commit d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2 and later

Vendor Advisory: https://github.com/lunary-ai/lunary/commit/d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2

Restart Required: Yes

Instructions:

1. Update lunary-ai/lunary to commit d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2 or later. 2. Restart the application. 3. Force all users to re-authenticate to invalidate old tokens.

🔧 Temporary Workarounds

Manual session invalidation

all

Force all users to log out and regenerate session tokens

# Clear session storage or invalidate all tokens in your deployment

API rate limiting

all

Implement rate limiting on PATCH requests to orgs endpoint

# Configure rate limiting in your reverse proxy or application middleware

🧯 If You Can't Patch

  • Implement middleware that validates user organization membership on every PATCH request to orgs endpoint
  • Deploy a web application firewall (WAF) with rules to detect suspicious PATCH requests from recently removed users

🔍 How to Verify

Check if Vulnerable:

Test if a removed user's old token can still make PATCH requests to /orgs endpoint

Check Version:

git log --oneline -1

Verify Fix Applied:

Verify that removed users receive 403 Forbidden when attempting PATCH requests to /orgs endpoint

📡 Detection & Monitoring

Log Indicators:

  • PATCH requests to /orgs endpoint from users not in current organization membership lists
  • Multiple failed authorization attempts followed by successful PATCH

Network Indicators:

  • Unusual PATCH request patterns to organization endpoints
  • Requests using old authorization tokens

SIEM Query:

source="application.logs" AND (method="PATCH" AND uri="/orgs") AND user_id NOT IN (SELECT user_id FROM organization_members WHERE organization_id=?)

🔗 References

📤 Share & Export