Safeguard
Vulnerability Analysis•

CVE-2024-5128: High IDOR in Lunary Dataset Endpoints

CVE-2024-5128 is a high severity IDOR in Lunary up to 1.2.2 that exposes dataset prompts across projects. Upgrade to the fixed build and verify it.

Safeguard Security Team
3 min read

CVE-2024-5128 is a high severity (CVSS 8.8) insecure direct object reference in lunary-ai/lunary through version 1.2.2. Users can view, update or delete dataset prompts in any project. The record says the fix landed in 1.2.25. Upgrade and confirm the version number.

What's affected

The record says versions up to and including 1.2.2 are affected and that the problem was fixed in version 1.2.25. Those two numbers look odd side by side, since 1.2.25 reads as a later patch of 1.2 only if the project uses plain integer minor and patch numbers. Check the Lunary release list to confirm the first fixed tag and do not rely on string sorting.

The affected area is the dataset management endpoints, specifically dataset prompts and dataset prompt variations. Three other Lunary CVEs published the same day cover related authorization and disclosure gaps.

How to check if you're exposed

For a self hosted Lunary, find the running version from the image tag or package manifest:

docker ps --format '{{.Image}}' | grep -i lunary
docker inspect --format '{{.Config.Image}}' <container>

Compare the tag against the first fixed release in the project's release notes. On the hosted service the maintainers handle patches, so confirm with their status notices. Also review whether untrusted users have accounts in your projects, since IDOR needs a logged in actor.

What to do now

  1. Upgrade Lunary to the fixed release and confirm the version afterwards.
  2. Review dataset prompts for unexpected edits or deletions, and restore from backup where needed.
  3. Limit who can sign up to your instance and remove accounts you do not recognize.
  4. Keep a regular database backup so deleted datasets can be recovered.
  5. Retest the dataset endpoints with two separate test projects after the upgrade, to confirm one cannot reach the other's items.

Why it matters

The weakness is CWE-639, authorization bypass through a user controlled key. The endpoint accepts an object ID and acts on it without confirming the object belongs to the caller's project. Change the ID and you reach someone else's record.

IDOR bugs are common in multi tenant applications because every endpoint has to repeat the ownership check. One missed check is enough. For a platform that stores LLM prompts and evaluation datasets, those records can hold proprietary instructions and test data. The record does not set the KEV flag.

Quick check

Do I need an account to exploit this?

The record says unauthorized users, and the related CVEs differ on whether login is needed. Assume an account is enough.

What is the fixed version?

The record says 1.2.25. Confirm against the Lunary releases page.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.