Critical Vulnerabilities Disclosed in NVIDIA Dynamo with Remote Attack Risks
NVIDIA has disclosed multiple vulnerabilities in its NVIDIA Dynamo software, a Linux-based solution designed for serving multimodal data. The issues were detailed in a security advisory published on August 4, 2026, affecting various versions with a combined total of 15 CVEs confirmed.
The most critical finding is CVE-2026-24254, an out-of-bounds write vulnerability in the multimodal serving topology. This flaw permits remote attackers to exploit it without authentication, earning a CVSS v3.1 base score of 9.8 and a Critical severity rating. A noted discrepancy exists between the score and the vector string, which may require future correction.
Two additional vulnerabilities follow with CVSS scores of 8.2. CVE-2026-24253 involves out-of-bounds memory writes that could lead to denial of service. CVE-2026-47623 arises from deserializing untrusted data, potentially enabling denial of service or data tampering.
Updated versions addressing these issues are now available from NVIDIA. Organizations using NVIDIA Dynamo should apply the patches promptly to reduce exposure to these remote attack vectors.
Related articles
CISA Adds JetBrains TeamCity CVE-2026-63077 to Known Exploited Vulnerabilities Catalog After Active Attacks
The US Cybersecurity and Infrastructure Security Agency has added a critical vulnerability in JetBrains TeamCity to its Known Exploited Vulnerabilities catalog due to confirmed exploitation in the wild. The flaw, tracked as CVE-2026-63077, stems from unsafe deserialization of untrusted data over the agent polling protocol and permits unauthenticated remote code execution. TeamCity is widely used for automating software build, test, and deployment pipelines in development environments. CISA directed all US federal agencies to apply vendor mitigations within three days, by August 8, 2026. Organizations running the continuous integration server are urged to review exposure and implement the recommended fixes immediately to prevent further compromise.
DLL Sideloading via version.dll in WinSCP: Search Order Exploitation, Rust Proxy and Payload Interception
WinSCP loads version.dll from its own directory because Windows searches for DLLs in a specific order starting with the application folder. Researchers demonstrated how to identify this library through the import table, Known DLLs exclusion, and Procmon monitoring to observe the loader attempting the AppDir path before falling back to SysWOW64. The same technique was recently used in campaigns targeting FileZilla via a fake domain and CPUID supply-chain compromises involving cryptbase.dll. A Rust-based proxy DLL forwards 14 exports via linker-level redirection while implementing three hijacked functions that trigger a MessageBox payload immediately upon WinSCP startup. The PoC was built for 32-bit WinSCP on Windows 11 using cargo and a generated .def file that adapts to x86 or x64 targets. This attack remains effective because version.dll is not listed in KnownDLLs and is directly imported by WinSCP, guaranteeing early execution before the main application window appears.
VK Introduces Security Gate: Internal AppSec Platform for Code, Dependency and Container Security
VK has detailed its internal Security Gate platform, which combines SAST, SCA, secret detection and container scanning to identify security issues across more than 40,000 repositories. The system applies custom prioritization rules, dynamic metadata analysis and an LLM-based triage module called VK Triage to reduce false positives and focus developer attention on exploitable findings. Security Gate integrates directly with corporate GitLab for automatic project onboarding, badge reporting and merge-request checks via the Fast Scanner service. It also monitors open-source dependencies for protestware, malware and reachable vulnerable methods, while supporting a wide range of languages including Python, Go, Java and Swift. Additional features include Jira linking, cross-branch triage, SBOM export and automated alerts through VK WorkSpace bots.
2.2 Million Line Vulnerability Report: What Happens After Discovery and How to Turn Findings Into Action
A massive vulnerability scan produced an 1,819-page report and a 2.2-million-row Excel file that exceeded spreadsheet limits, highlighting the gap between detection and remediation. The article explains that finding vulnerabilities accounts for only 10 percent of the work, while the remaining 90 percent involves prioritization, remediation, verification, and ensuring issues do not reappear. Research from BI.ZONE, Sber, Qualys, Cyentia Institute, Kenna Security, and Hadrian shows that organizations can typically remediate only one in ten open vulnerabilities per month and that Time-to-Exploit has dropped dramatically, with many edge-device flaws exploited on the day of disclosure. The piece stresses that continuous scanning, full infrastructure coverage including shadow IT, and separate high-frequency perimeter scans are essential because 85 percent of KEV-vulnerable assets remain unpatched at disclosure time. It recommends replacing bulky reports with concise, role-specific registries that answer four questions: what to do, where to do it, by when, and the consequences of inaction. Three legitimate outcomes for every vulnerability are outlined: patching, compensating controls, or formal risk acceptance with defined review dates, while false positives such as orphaned OpenSSL libraries must be cleaned rather than ignored.