CVE-2025-65896

What it actually does

The flaw is an SQL injection in long2ice assyncmy through version 0.2.10 where untrusted dictionary keys are incorporated into SQL construction without sufficient parameterization or identifier validation. An attacker who can influence those keys can alter the resulting SQL statement, allowing arbitrary SQL execution in the context of the application's database user. Depending on database privileges, this can lead to unauthorized data reads, data modification or deletion, authentication bypass, creation of new records or users, and in some database configurations further server-side actions. The supplied affected-package metadata also lists Ubuntu kernel package lines with fixed versions; because that does not naturally align with the described assyncmy SQL injection, engineering teams should verify advisory-to-package mapping before relying solely on package names for exposure decisions.

Why it matters to the business

Successful exploitation can compromise the confidentiality and integrity of application data, disrupt business workflows, and create regulatory or contractual reporting obligations if sensitive data is exposed. Because the CVSS score is critical, reachable applications using the vulnerable SQL-building path should be treated as high priority even though EPSS is currently low, the vulnerability is not in CISA KEV, ransomware use is not reported, and no public exploit maturity is indicated. The issue has been public for 250 days, which increases the chance that attackers or scanners may eventually incorporate it despite the currently low observed exploitation signal.

How an attack unfolds

An attacker first identifies an application endpoint, job, API, or internal service path that passes attacker-controlled dictionary data into assyncmy's SQL generation logic. They then craft a dictionary key that is syntactically meaningful to the SQL engine instead of being treated as a safe column or field name. When the vulnerable code builds the query, the malicious key changes the SQL statement structure, enabling the attacker to run unintended SQL commands. The attacker may begin with harmless probing that causes SQL errors or timing differences, then enumerate database behavior, extract data, modify records, or use database-specific features to deepen access where permissions allow. No named threat actor activity, KEV listing, ransomware campaign use, or mature public exploit is reported in the supplied data, so exploitation should be assessed primarily from local exposure and evidence in application and database logs.

How to fix it

Upgrade long2ice assyncmy to a version later than 0.2.10 once a fixed release is available from the maintainer, or remove/replace the dependency if no fixed version is published. As a code-level mitigation, never interpolate dictionary keys or other untrusted identifiers directly into SQL; use parameterized queries for values, strict allowlists for column/table identifiers, ORM-safe query builders, and reject keys containing SQL metacharacters or unexpected field names. Restrict the database account used by affected applications to the minimum privileges required, removing dangerous permissions such as broad write, schema modification, file access, or administrative capabilities. Enable database query logging and application input validation around affected paths. For environments where the supplied Ubuntu package mapping is applicable, ensure packages are at or above: linux Ubuntu 14.04 LTS 3.11.0-12.19; linux-azure Ubuntu 16.04 LTS 4.15.0-1111.123~16.04.1; linux-gcp Ubuntu 16.04 LTS 4.15.0-1096.109~16.04.1; linux-hwe Ubuntu 16.04 LTS 4.15.0-140.144~16.04.1; linux-azure Ubuntu Pro 14.04 LTS 4.15.0-1111.123~14.04.1. Because the package metadata appears inconsistent with the described SQL injection component, validate the affected component inventory directly rather than assuming kernel updates alone remediate application-level exposure.

How to confirm the fix worked

Confirm whether long2ice assyncmy is present and at what version using dependency manifests, lockfiles, package inventories, container images, and runtime environment inspection. Verify that no deployed application uses assyncmy version 0.2.10 or earlier in code paths reachable by untrusted input. Review source code or generated SQL to confirm dictionary keys are validated against an explicit allowlist and are not concatenated into SQL. In test environments, use benign negative tests with unexpected key names and confirm they are rejected before query generation rather than producing SQL errors or altered query behavior. Confirm database accounts used by affected applications have least-privilege permissions. If relying on the supplied Ubuntu package data, verify installed package versions meet or exceed the listed fixed versions and reboot where kernel updates are applicable.

Typical attack path

1. Find an application, API, worker, or service that uses long2ice assyncmy through 0.2.10 and accepts structured input that becomes dictionary keys for database operations.
2. Submit crafted dictionary keys containing SQL syntax or control characters intended to alter the generated query.
3. Observe SQL errors, response differences, timing behavior, or data changes to confirm that the key is being interpreted as SQL.
4. Escalate from validation to arbitrary SQL execution, such as reading tables, changing records, deleting data, or bypassing application logic.
5. Use obtained data or modified application state for fraud, account takeover, persistence, or lateral movement depending on database contents and privileges.

How to detect it

To determine whether exploitation already occurred, review application access logs, API gateway logs, WAF events, structured request bodies, and debug logs for suspicious JSON or dictionary key names containing SQL syntax. Because exploitation occurs through crafted dict keys, do not limit hunts to parameter values; inspect field names, object keys, form parameter names, and query-string parameter names. Review application exception logs for database syntax errors, stack traces referencing assyncmy, unexpected query construction failures, or messages such as malformed SQL near user-supplied field names. Review database audit logs and slow query logs for statements containing unusual comments, tautologies, stacked statements, UNION probes, timing functions, or schema enumeration issued by the application service account. Look for unusual database activity from the application account, including reads of sensitive tables outside normal access patterns, bulk exports, unexpected UPDATE/DELETE statements, creation of new users or tables, or privilege changes. Correlate suspicious requests with database queries at the same timestamp and source IP. No exploit-specific file artifact, process name, registry key, named threat actor infrastructure, or ransomware-specific IOC is derivable from the supplied information.

• assyncmy
• SQL syntax
• syntax error at or near
• You have an error in your SQL syntax
• sqlite3.OperationalError
• psycopg2.errors.SyntaxError
• ProgrammingError
• UNION SELECT
• UNION ALL SELECT
• information_schema
• sqlite_master
• pg_catalog
• OR 1=1
• ' OR '1'='1
• " OR "1"="1
• --
• /*
• */
• ; DROP TABLE
• ; DELETE FROM
• ; UPDATE
• SLEEP(
• pg_sleep(
• WAITFOR DELAY
• benchmark(

What your security team should do

• Prioritize internet-facing or partner-facing applications using long2ice assyncmy through 0.2.10, even though EPSS is currently low and KEV status is false.
• Create an inventory query across repositories, dependency manifests, SBOMs, virtual environments, containers, and build artifacts for assyncmy and long2ice assyncmy references.
• Engage application owners to upgrade, remove, or patch the vulnerable SQL construction path and require allowlisted identifiers for all dynamic query fields.
• Enable or temporarily increase application error logging, database statement logging, and WAF/API telemetry for endpoints that accept structured object or dictionary input.
• Hunt for SQL injection probing in request parameter names, JSON object keys, API payload keys, database logs, and application exception traces since this issue is triggered through keys rather than only values.
• Review database privileges for affected services and reduce permissions to limit blast radius if exploitation occurs.
• Validate the advisory/package mapping because the supplied affected products reference Ubuntu kernel package lines while the vulnerability description identifies an application library SQL injection.
• Track vendor advisories for a definitive assyncmy fixed release and monitor for any change in exploit maturity, EPSS trend, or KEV status.