ZeroHour

Vulnerabilities

3 CVEs · NVD, GitHub Advisories, CISA KEV, FIRST EPSS, GitHub PoC repos

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-79551
Hardcoded Cryptographic Key in Tenda NVR_4H CH3 v2.1

Tenda NVR_4H CH3 v2.1 running firmware V27.5.58.6 contains a hardcoded cryptographic key embedded in the device firmware. An attacker who extracts the key — for example from a downloadable firmware image or via the public proof-of-concept published on GitHub — could use it to defeat the device's cryptographic protections, such as decrypting captured traffic, forging authenticated sessions, or bypassing encryption depending on where the key is used. This affects organizations and home users deploying this Tenda network video recorder model, which is typically used for IP camera surveillance in SMB and residential settings. A public PoC exists, but the CVE is not in the CISA KEV catalog and there is no confirmed evidence of in-the-wild exploitation at this time.

Do: Check Tenda's official support site for a firmware update for the NVR_4H CH3 and apply it if one addresses this issue; Tenda has not stated a fixed version. In the meantime, remove the NVR from direct internet exposure (place it behind a VPN or firewall), rotate any credentials configured on the device, and monitor logs for unexpected logins or configuration changes. Because a hardcoded key cannot be changed by configuration, isolation and patching are the primary mitigations.

PoC
  • Tenda Technology Co., Ltd NVR_4H CH3 v2.1 (firmware V27.5.58.6)
moderatelikely low thousands to ~10,000s of deployed units, with an unknown subset internet-exposed
CVE-2026-79303
SQL Injection in kaiten versions 57.192.20 through before 57.214.26

kaiten versions from 57.192.20 up to (but not including) 57.214.26 are vulnerable to SQL injection because dynamic SQL statements are constructed without adequate input validation and without parameterized queries or stored procedures. An attacker can inject crafted input into a vulnerable parameter, causing the application to execute attacker-influenced SQL against the backend database. Successful exploitation could allow reading or modifying sensitive data, bypassing authentication, or, depending on database configuration, executing further attacks against the underlying server. All deployments running the affected version range are exposed wherever the vulnerable input is reachable, and a public proof-of-concept is available on GitHub, lowering the barrier for attackers. The flaw is not yet in CISA's Known Exploited Vulnerabilities catalog and no confirmed in-the-wild exploitation is documented, but the public PoC means active abuse is plausible.

Do: Upgrade kaiten to version 57.214.26 or later as soon as it is available. Until patched, restrict access to the affected functionality and apply WAF or database-layer rules to filter common SQL injection patterns. Review database and application logs for anomalous queries or unexpected data access that could indicate exploitation attempts.

PoC
  • kaiten from 57.192.20 to before 57.214.26
CVE-2026-12944
SSRF-Driven Root Code Execution in IBM Langflow OSS 1.0.0–1.10.0

IBM Langflow OSS versions 1.0.0 through 1.10.0 allow a low-privileged attacker to submit workflow components containing socket or urllib imports, which the server executes as arbitrary Python code with root privileges (UID=0) inside the Langflow container. The built-in validation scanner incorrectly returns 'validated': true for these malicious components, giving operators a false sense that submitted flows are safe. Successful exploitation enables AWS credential theft via IMDSv1 SSRF using the instance's full IAM role permissions, arbitrary file exfiltration from the container filesystem, and lateral movement to internal services such as PostgreSQL and Redis on the Docker network. Anyone running a self-hosted Langflow server in the affected range that permits untrusted or semi-trusted users to build and submit flows is affected. The flaw is rated critical (CVSS 9.6), but no public proof-of-concept, known in-the-wild exploitation, or CISA KEV listing exists at this time.

Do: Upgrade IBM Langflow OSS to a version newer than 1.10.0 as soon as IBM releases a fix, and check the IBM PSIRT advisory for the patched build. Do not rely on the component validator's 'validated': true signal — treat all user-submitted components as untrusted and restrict who can create or import flows. Harden the environment by running the container as a non-root user, enforcing IMDSv2 (disable IMDSv1) on cloud hosts, segmenting the Docker network from databases like PostgreSQL/Redis, and rotating AWS credentials and other secrets if untrusted flows were ever executed.

9.6<1% PoC
  • IBM Langflow OSS 1.0.0 through 1.10.0
moderate≈ low thousands of internet-exposed Langflow instances, plus an unknown larger number of internal/self-hosted deployments