CVE-2024-0455 highlights a critical security oversight in AnythingLLM, an AI-driven platform that lets users connect, manage, and control LLM-powered apps and workflows. The vulnerability is not a flaw in code permission, but stems from the misuse possibility of the platform’s own features—specifically, the web scraper tool that users with manager, admin, or single-user privilege can access.

In plain terms, it allows authorized users to scrape internal cloud provider metadata—gaining access to powerful credentials that manage the entire cloud instance. Here’s how and why it’s dangerous.

What’s the Problem?

Many cloud service providers, including Amazon Web Services (AWS), expose instance metadata through a non-public IP—169.254.169.254. This special IP delivers sensitive information like instance names, roles, and, most importantly, temporary access keys (secrets) for the instance’s role.

Normally, this IP is only reachable *from within* the cloud server itself. But if an application (like AnythingLLM’s scraper) lets users supply any URL to fetch and display its content, then a savvy (or malicious) user can ask the scraper to fetch:

http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

If the AnythingLLM server is running on an EC2 instance, this request will succeed and return something like:

{
    "AccessKeyId": "ASIAxxxxxxxxxxxx",
    "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxx",
    "Token": "FwoGZXIvYXdzEJr//////////wEaDJxxxxxxxxxxxxxx",
    "Expiration": "2024-06-17T11:57:15Z"
}

These are full AWS credentials for the server’s IAM role.

Why is This Bad?

If a user manages to get these credentials, they can act as the EC2 server itself. Depending on the server’s assigned permissions, they might be able to:

Escalate privileges further

And all this, *even if they never had those permissions via the AnythingLLM app*.

The AnythingLLM instance must be running on AWS EC2.

- No firewall/iptables rule blocks 169.254.169.254 traffic from the AnythingLLM server.

`

http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Example Snippet

Supposing AnythingLLM’s scraper uses Python’s requests library (or similar), the backend might process this snippet:

import requests

url = "http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"
r = requests.get(url, timeout=5)

# This will print/return the AWS creds in JSON format
print(r.text)

The web interface will now show secrets like AccessKeyId, SecretAccessKey, and SessionToken.

Who is Affected?

- Admins/managers on the system can always use this, but the real risk is if you grant more users access or in single-user environments (like demos and testing).
- This affects Any app that exposes a fetch-from-URL action, runs on EC2, and does not block metadata URLs.
- Failure to restrict IP traffic inside the EC2 instance makes this possible. IAM instance metadata docs explain the dangers.

How to Fix

1. Block metadata IP: Update iptables or firewall to block outgoing requests to 169.254.169.254 from your application server. For example:

`

2. Input validation: In AnythingLLM, restrict user-submitted URLs. Block private/internal metadata IPs:

`

3. Use IMDSv2: It requires a session token, making simple requests harder for SSRF-style attackers.

4. Never grant users unrestrained scraping/fetching on your LLM platforms—even if internal.

References

- AWS EC2 Instance Metadata Security Best Practices
- AWS Docs: Instance Metadata Service
- AnythingLLM Github
- AWS Blog: Defense-in-Depth Open Source SSRF Best Practices
- Exploit Example Writeup (External)
- NVD Entry (pending/placeholder): CVE-2024-0455 (will be here)

Final Thoughts

CVE-2024-0455 is less about code bugs and more about “feature abuse”—letting advanced users point trusted apps to internal resources. For cloud-hosted platforms, *always* treat in-app web scrapers and fetchers as potential security boundaries, and assume internal IPs must be protected.

If you run AnythingLLM (or any app with a fetch-from-URL ability) in the cloud, patch your firewall, update your threat models, and validate your inputs. Otherwise, the “innocent” tools you add for convenience might open the door to your entire cloud.


*This post is original and exclusive—share it with your devops and security team!*

Timeline

Published on: 02/26/2024 16:27:50 UTC
Last modified on: 02/26/2024 16:32:25 UTC