CVE-2024-35515

What it actually does

Insecure deserialization in sqlitedict up to v2.1.0 permits loading of untrusted serialized data, resulting in arbitrary code execution within the application process.

Why it matters to the business

Attackers can gain full control over affected systems, leading to data theft, service disruption, or unauthorized access across environments using this library.

How an attack unfolds

An attacker supplies a malicious serialized payload to the library's deserialization routine, which executes attacker-controlled code upon loading without validation.

How to fix it

Upgrade sqlitedict to a version beyond 2.1.0 that enforces safe deserialization practices; avoid loading untrusted data and implement input validation or sandboxing where upgrades are delayed.

How to confirm the fix worked

Review application dependencies for sqlitedict versions at or below 2.1.0, test deserialization paths with known-safe payloads, and verify that malicious payloads no longer execute code after updates.

Typical attack path

1. Identify an application or service using sqlitedict for data storage or retrieval
2. Craft a malicious serialized object containing arbitrary code
3. Deliver the payload via network input, file, or database entry processed by the library
4. Trigger deserialization to execute the embedded code and establish control

How to detect it

Examine application logs for unexpected process spawns or errors during data loading, review network traffic or file inputs feeding into sqlitedict usage, and audit recent changes to stored data objects.

What your security team should do

• Scan all Python environments and dependency manifests for sqlitedict <= 2.1.0 and prioritize upgrades
• Implement runtime monitoring for unexpected code execution or process anomalies in applications using the library
• Restrict deserialization to trusted sources only and add serialization format validation