Unicode Tricks Let Malicious Python Code Bypass Code Review
A subtle but powerful class of attacks allows source code to pass human review while executing completely different logic. The root cause lies in the gap between how fonts render Unicode characters and how the Python interpreter reads the underlying bytes.
The first technique uses homoglyphs. An attacker can declare is_admin = False followed by a second assignment that looks identical but actually uses the Ukrainian letter і (U+0456) instead of Latin i (U+0069). The review sees a single variable being set to True, yet the interpreter creates two separate identifiers. The same substitution works for function names such as validate_token, causing the wrong implementation to run in production.
Python normalizes identifiers with NFKC, which collapses some visually similar characters but leaves Cyrillic letters untouched. Consequently, the attack remains effective in real codebases.
The second technique relies on bidirectional override characters (RIGHT-TO-LEFT OVERRIDE U+202E and related controls). These characters are required for Arabic and Hebrew text, yet they also allow an attacker to reorder source lines visually. A comment that appears harmless on screen can actually contain executable statements once the compiler ignores the display order. The technique became widely known in 2021 as the Trojan Source attack and affects nearly every mainstream programming language.
The third, simpler method inserts zero-width characters (U+200B, U+2060, etc.) inside string literals. The string 'password' has length nine and will never equal the expected value, yet the difference is invisible to the naked eye and defeats both manual inspection and simple grep searches.
A compact detection script walks the source with Python’s tokenize module and separately scans for bidirectional and zero-width characters. Checking only identifier tokens prevents false positives from comments and string data. The same logic is available as built-in rules in ruff and flake8, while gitleaks can block commits containing the dangerous characters.
Teams are advised to run the check across existing repositories, integrate it into CI pipelines, and treat any intentional insertion of these characters as a serious red flag during incident review.
Related articles
Protestware: How Ideologically Motivated Attackers Compromise Open Source Code and Supply Chains
Protestware represents a growing supply chain risk where open source maintainers deliberately insert destructive or politically motivated code into widely used packages. Unlike traditional malware seeking financial gain, protestware is driven by ideological motives and can delete files, cause denial of service, or restrict functionality based on geography or locale. Notable incidents include the node-ipc and peacenotwar packages that overwrote files on systems in Russia and Belarus, the colors.js infinite loop causing DoS, and es5-ext triggering high CPU usage during specific hours or Russian locales. These attacks often hide in postinstall hooks, use geolocation checks via ipinfo.io, or activate via environment variables and timestamps. Detection requires static analysis for geo-IP logic, dynamic monitoring in sandboxes, and tools such as Software Bill of Materials and OpenSSF Scorecard. Organizations are advised to adopt Zero Trust for dependencies, pin versions, use internal artifact repositories, and follow frameworks including NIST SSDF and SLSA to mitigate risks.
Attackers Exploit Critical JFrog Artifactory Flaw CVE-2026-82329 to Forge Admin Tokens and Poison CI/CD Pipelines
A critical vulnerability tracked as CVE-2026-82329 in JFrog Artifactory is being actively exploited in the wild, allowing unauthenticated attackers with network access to generate or forge administrator tokens on self-managed installations that retain default settings. The flaw enables full authentication bypass, granting attackers administrative privileges to enumerate users and groups, access sensitive configurations, read stored artifacts, and modify security settings. The greatest risk arises when Artifactory serves as the central repository for automated CI/CD pipelines, where an attacker can replace trusted internal packages, container images, or dependencies and propagate malicious changes downstream into build runners and production environments. JFrog has released patches for multiple branches, including versions 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20, although patching alone does not invalidate already-issued tokens. Organizations are advised to restrict network exposure, revoke and rotate admin tokens, review audit logs for anomalous token generation and configuration changes, and validate artifact integrity across the vulnerable period. The issue does not affect JFrog Cloud instances.
Critical JFrog Artifactory Flaw CVE-2026-82329 Actively Exploited to Forge Admin Tokens in Self-Managed Deployments
A critical vulnerability identified as CVE-2026-82329 in JFrog Artifactory is being actively exploited in the wild, enabling unauthenticated attackers to generate or forge administrator tokens simply by having network access to affected instances. The flaw impacts self-managed installations that retain default configurations, a common scenario when repositories are deployed quickly and later exposed to the internet. Once administrative access is obtained, attackers can enumerate users and groups, access sensitive configurations, read stored artifacts, and modify security settings. The most severe risk arises when Artifactory automatically feeds CI/CD pipelines, allowing malicious substitution of trusted packages, container images, or dependencies that then propagate downstream into production environments. JFrog Cloud instances were already protected, while self-managed deployments require updates to specific patched versions including 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. Even after patching, previously issued tokens must be revoked because their validity operates independently of the software update. Organizations are advised to restrict network exposure, rotate credentials, audit token generation logs, and validate artifact integrity for any material published during the vulnerable period.
redb 3.7.2 Released with Custom gRPC Protocol, Dependency Vulnerability Fixes and .NET 10 Migration
The redb ecosystem released versions 3.7.0, 3.7.1 and 3.7.2 in quick succession after 3.7.0 was withdrawn due to high-severity vulnerabilities in its .NET 9 build artifacts. NuGet audit detected issues only on full rebuilds, leading to updates for SSH.NET, Microsoft.Data.Sqlite, System.Security.Cryptography.Xml and Microsoft.Bcl.Memory across redb.Route, redb.Core, redb.Export and redb.Identity. The release introduces a native GrpcWire implementation that registers individual gRPC methods as routes on a shared Kestrel host, supports bidirectional streaming, real gRPC status codes and mTLS with pinned client certificates. redb.Route also gained a dedicated SOAP connector, Control Bus messaging for route lifecycle management and a corrected Claim Check pattern. File transports received critical fixes that prevent silent data loss when readLock and idempotency options are combined. All libraries now target net8.0;net9.0;net10.0 while host applications require .NET 10, aligning with Microsoft’s shortened support timeline for .NET 8 and 9.