Secure Error Logging Practices to Prevent Information Leaks Across Java, Kotlin, JavaScript and Python
Error logging forms a critical part of the software development lifecycle, aiding debugging and early detection of failures. However, logs must remain both informative and secure to avoid unintended information disclosure.
The article, written by Natalia Noyanova of T1 IT Holding, draws on years of experience in information security and static code analysis. It highlights how code analyzers flag internal or external information leaks tied to error logging and explains why fixing these issues requires more than simple code changes.
Logging levels range from DEBUG (detailed diagnostic data not used in production) through INFO, WARNING, ERROR to FATAL (critical errors that halt the application). Recording mechanisms include plain text files, multi-stage logs requiring special readers, binary formats and databases.
Trace ID provides a unique technical identifier generated at the API gateway for each incoming request and propagated unchanged through all microservices. Correlation ID links multiple technical requests that belong to one business transaction, such as an order placement involving inventory, payment and confirmation steps.
Examples of exploitation include Flask applications running with debug=True that return full stack traces revealing absolute paths like /app/main.py and Python interpreter versions. Similar leaks occur when developers manually return traceback.format_exc() or forward raw SQLite errors after failed queries, confirming the database engine and aiding SQL injection refinement.
Prevention measures cover removal of X-Powered-By and Server headers via Nginx server_tokens off, input sanitization with regular expressions to block newlines in trace identifiers, and adoption of OpenTelemetry for automatic generation of safe hex-formatted trace IDs. Structured JSON logging further isolates fields and prevents log injection attacks described under CWE-117.
Related articles
eBPF Verifier Discrepancy Revealed: PREVAIL Accepts Safe Code Rejected by Linux Kernel Verifier
Researchers discovered that the same BPF object file receives conflicting verdicts from different verifiers. The program correlated_branch.c from the ebpf-samples repository passes verification under PREVAIL but is rejected by the Linux kernel verifier. The divergence occurs because the kernel verifier tracks scalar bounds separately from packet pointer offsets, while PREVAIL maintains explicit links between checked packet sizes and pointer states. The XDP function ConvergedBranch performs a bounds check via check_packet before accessing an Ethernet header, yet the kernel verifier fails to propagate the guarantee to the subsequent load instruction. Replacing the helper call with an inline comparison against data_end allows the kernel verifier to accept the program. The finding highlights that verifier rejection does not always indicate an actual safety violation in eBPF code.
Critical ASUS Control Center Enterprise Flaw Allows Remote Root Access via CVE-2026-75754
A critical vulnerability identified as CVE-2026-75754 in ASUS Control Center Enterprise (ACC) carries a maximum CVSS score of 10.0 and enables unauthenticated remote attackers to gain full control of the management server and all connected devices. The flaw stems from a combination of missing authentication on a critical function, a server-side request forgery (SSRF) issue, and hardcoded credentials embedded directly in the software. Attackers can craft a malicious HTTP request to extract the system’s encryption key, activate an SSH service on TCP port 2222, and use fixed credentials to obtain a root shell without any user interaction. Once inside, the attacker can read, modify, or delete data stored in the ACC platform and propagate the compromise across managed servers, PCs, and workstations. All versions of ASUS Control Center Enterprise through 4.0.0.2 are affected. ASUS released a security advisory on September 4, 2026, urging immediate updates to mitigate the risk.
Critical Zero-Day 'StyleSmuggler' Vulnerability Exploited in Adobe Commerce and Magento
A zero-day vulnerability dubbed StyleSmuggler is being actively exploited in Magento Open Source and Adobe Commerce to achieve unauthenticated remote code execution and install backdoors on e-commerce servers. The flaw allows attackers to inject malicious PHP code into files generated by the platform and then force the template system to process it, with the attack chain triggered during the generation of default transaction failure emails. Exploitation has been observed since September 4 and works even if the email is not successfully sent. Researchers have reproduced the attack on clean installations of versions 2.4.7, 2.4.8, and 2.4.9, as well as on a fully patched Magento 2.4.6-p15 system. After compromise, a Rust-based implant is deployed outside the store directory, masquerading as the process [kworker/u:8:0] and maintained via a cron job that restarts it every five minutes. As of September 6, Adobe had not released a CVE, official patch, or specific workaround, though the next scheduled security update is set for September 8.
N-able Releases Hotfix 4 for Critical N-central RCE Flaw CVE-2026-86218 Now Confirmed Exploited
N-able disclosed a critical vulnerability in its N-central IT operations management platform that allows unauthenticated remote code execution on affected servers. The flaw, tracked as CVE-2026-86218, received the maximum CVSSv4.0 base score of 10.0 and is rated Critical. The company published security advisory information on September 5, 2026, and quickly followed with Hotfix 4 (version 2026.3.1.14) that resolves the issue. Although exploitation was not observed at disclosure, N-able updated the advisory the next day to confirm active exploitation in the wild. The vendor urges customers to apply the hotfix immediately and to monitor for suspicious account creation and scanning activity from specific IP addresses. Earlier hotfixes addressing CVE-2026-86206 and CVE-2026-86207 were superseded by the new release.