CVE-2026-58041

What it actually does

The flaw is in Node.js built-in node:sqlite support for cached tagged SQL statements. A stale StatementSyncIterator created through DatabaseSync#createTagStore() can continue executing a prepared statement after SQLTagStore has reset and rebound that cached statement with new parameters. Because sqlite3_reset() is called directly, the iterator invalidation behavior expected for StatementSync is bypassed. In vulnerable applications, this can cause SQL execution to proceed with parameters or statement state from a later operation rather than the operation that originally created the iterator, creating an integrity risk such as unintended inserts, updates, deletes, or authorization-sensitive query behavior.

Why it matters to the business

Applications using the affected Node.js node:sqlite APIs may perform database operations with the wrong bound values, which can lead to incorrect records being changed, corrupted application state, or unauthorized business actions if attacker-controlled input influences the relevant queries. The issue currently has low EPSS, no known KEV listing, no ransomware association, and no public exploit maturity reported, but it affects active Node.js release lines 22.x, 24.x, and 26.x, so organizations using the built-in sqlite module should treat it as a targeted application-integrity risk rather than broad internet-scale exploitation.

How an attack unfolds

An attacker must interact with application functionality that uses Node.js node:sqlite, DatabaseSync#createTagStore(), and cached tagged SQL statements in a pattern where an iterator remains alive while the same cached statement is reset and rebound with new parameters. The attacker supplies inputs or sequences requests to trigger one query that creates a StatementSyncIterator, then triggers another use of the same cached statement with attacker-chosen parameters. Because the old iterator is not invalidated correctly, continued iteration can execute against the statement after it has been rebound. If the affected SQL statement performs or drives sensitive state changes, the attacker may cause the application to apply unintended values, update the wrong records, or otherwise violate application integrity constraints. Exploitation is application-specific and requires a vulnerable code path; it is not a standalone remote compromise of Node.js by itself.

How to fix it

Upgrade Node.js 22.x, 24.x, and 26.x installations to a vendor release that contains the fix for this vulnerability as soon as one is available for the deployed release line. Until patched, avoid using DatabaseSync#createTagStore() and SQLTagStore for security-sensitive operations, especially where iterators can remain live while cached statements are reused. Prefer non-cached prepared statements or ensure statements and iterators are fully consumed, finalized, or discarded before any reuse. Review code for shared tag-store usage across request boundaries or complex control flow, and refactor so each operation has isolated statement lifecycle management. If the application cannot be patched immediately, consider disabling affected functionality, serializing access to relevant database operations, or replacing node:sqlite usage with a non-vulnerable database access pattern.

How to confirm the fix worked

Confirm the deployed Node.js runtime version with node -v and compare it against the patched release advisory for the active 22.x, 24.x, or 26.x line. Review application dependency manifests, container images, base images, serverless runtimes, and CI build images to ensure the patched Node.js runtime is actually in use at runtime. Inspect source code for imports of node:sqlite and use of DatabaseSync#createTagStore(). Add or run a regression test that creates an iterator from a tag-store cached statement, reuses the same cached statement with different parameters, and verifies the original iterator cannot continue with rebound state. Validate that security-sensitive database workflows still produce correct results under concurrent, repeated, or interleaved request sequences.

Typical attack path

1. Identify or infer an application endpoint or workflow backed by Node.js node:sqlite using tagged SQL statement caching.
2. Supply input that causes the application to create a StatementSyncIterator from a cached SQLTagStore statement.
3. Keep the application workflow in a state where the iterator can continue to be consumed after its initial creation.
4. Trigger another request or action that reuses the same cached statement and rebinds it with different, attacker-influenced parameters.
5. Cause the stale iterator to continue executing after the cached statement has been reset and rebound.
6. Leverage the resulting parameter confusion to cause incorrect database changes or application state transitions.

How to detect it

There are no universal host, network, or file indicators that prove exploitation because successful abuse manifests as application-specific database integrity anomalies. To investigate possible prior exploitation, review application logs for endpoints or workflows that use node:sqlite tag-store queries and look for unusual request ordering, repeated rapid submissions, interrupted or long-running result iteration, or unexpected state transitions. Correlate those events with database audit logs for anomalous inserts, updates, deletes, or records modified with values that match a different user action or request. Review error logs for sqlite or application-level iterator/state-management exceptions around the same time. Source-code and runtime exposure checks should search for node:sqlite imports and DatabaseSync#createTagStore() usage, but those identify exposure rather than compromise.

What your security team should do

• Inventory services, containers, and build artifacts running Node.js 22.x, 24.x, or 26.x and using the built-in node:sqlite module.
• Prioritize review of applications that use DatabaseSync#createTagStore() for write operations, authorization decisions, financial transactions, inventory changes, account changes, or other integrity-sensitive workflows.
• Patch Node.js to the fixed release for the deployed major version as soon as vendor-fixed builds are available.
• If patching is delayed, temporarily remove or refactor SQLTagStore usage and avoid long-lived iterators over cached statements.
• Ask engineering teams to add regression coverage for statement iterator invalidation and parameter isolation.
• Monitor application and database audit logs for unexpected updates, deletes, inserts, or state transitions in workflows backed by node:sqlite.
• Because the issue is not currently in KEV and EPSS is low, handle as a focused application risk while maintaining normal vulnerability-management SLAs unless affected code performs high-value state changes.