Researcher Achieves SSTI-Based Defacement of First Partner Bank Web Service on Standoff 365
A researcher publishing under the handle grizzzer has published a detailed account of how a critical event was completed on the Standoff 365 online polygon: defacing the digital banking web service of First Partner Bank.
The target application ran at dbo.fpb.stf. Initial reconnaissance used a DNS zone transfer from the authoritative server at 10.124.1.34, which disclosed four hosts including the banking service itself.
After adding the discovered hosts to /etc/hosts, the researcher opened the login page and used Wappalyzer to identify the technology stack: React, Express, and Node.js. An interesting server-rendered endpoint was found at /docs-server/receipt that accepted an email parameter and returned HTML generated by a server-side template engine.
Fuzzing additional parameter names with Burp Suite Intruder revealed that the undocumented pretty parameter was interpreted by the Pug template engine because the application passed the entire req.query object into pug.renderFile via the spread operator. This classic SSTI condition allowed an attacker-controlled value to be injected into the generated JavaScript output.
A carefully crafted payload closed the existing string context and used process.mainModule.require to import the net and repl modules, establishing a reverse shell that provided an interactive Node.js REPL. From this shell the researcher located the file /app/public/locales/en/translation.json, which contained interface strings loaded by the React frontend.
Using a single writeFileSync command, the value of the info.welcome-to key was replaced with the string pwned by VON. Because the React application fetches the JSON file on every page load, the modified text immediately appeared on the authorization page for all users without requiring a server restart.
The complete attack path was: DNS AXFR reconnaissance, parameter fuzzing, exploitation of Pug SSTI, Node.js RCE, and modification of the localization file. The researcher emphasized that the root cause was unsafe handling of user input inside the template engine and provided several concrete mitigation steps, including restricting DNS zone transfers, updating Pug to version 3.0.3 or later, and avoiding direct forwarding of query parameters into template options.
Related articles
ServiceNow Discloses Three CVSS 10.0 Vulnerabilities Allowing Unauthenticated Remote Code Execution and SQL Injection
ServiceNow has released security updates addressing four vulnerabilities in its AI platform, including three rated CVSS 10.0. The flaws enable unauthenticated attackers to achieve remote code execution, privilege escalation, and arbitrary SQL execution against core ITSM systems used by large enterprises worldwide. Affected components include the GraphQL Composite Data API, system configuration image upload processor, and dynamic schema ORDER BY handling. ServiceNow states it has patched hosted instances and provided hotfixes for self-hosted customers running Xanadu, Yokohama, Zurich, and Australia branches. This follows a July disclosure of a related sandbox escape tracked as CVE-2026-6875 that showed signs of in-the-wild exploitation. No public exploits or confirmed active attacks have been observed for the new issues yet, but the extremely low attack complexity leaves a narrow remediation window for organizations running exposed instances.
AI Agent Uncovers Unauthenticated Router Config Dump Leading to CVE Filing
An LLM agent tasked only with documenting network topology independently discovered a critical authentication bypass in a home router firmware. The agent performed read-only reconnaissance, extracted the full configuration including base64-encoded admin passwords and WPA2 keys via an unprotected CGI endpoint, and verified the finding by obtaining a valid session cookie. It then produced a complete coordinated disclosure report, classified the issue under CWE-306 with a CVSS 3.1 score of 8.8, and prepared the MITRE CVE submission package. The vulnerability affects LAN-side management interfaces of certain SOHO routers running legacy Boa web servers and remains unpatched due to inaccessible vendor firmware channels. The researcher maintained strict read-only permissions for the agent throughout the process, ensuring no configuration changes occurred. The case demonstrates how autonomous agents can accelerate vulnerability research while staying within defined operational boundaries.
AutoAddPolicy in Paramiko Disables Host Key Verification and Risks Credential Leakage After IP Reassignment
A developer discovered that fourteen deployment and management scripts all contained hardcoded references to a single VPS IP address. When the provider reassigned the address after migration, the scripts connected to an unrelated server belonging to another customer. The root cause was the line ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()), which silently accepts any host key instead of raising an exception. The connection succeeded, the root password stored in VPS_PASS was transmitted, and the operation appeared successful in logs. The author replaced AutoAddPolicy with RejectPolicy, centralized the address in a single vps.py module, and switched to key-based authentication with a password fallback. The same class of issue appears in web tools that fetch arbitrary URLs, requiring strict scheme, IP-range, and redirect checks to block SSRF vectors such as 127.0.0.1 and 169.254.169.254. The case demonstrates that host-key verification protects against routine cloud IP reuse rather than only theoretical man-in-the-middle attacks.
Developer Exposes 12 Vulnerabilities in FastAPI Todo App After 176 Bots Bypass Protections
A developer building a student-focused todo planner on FastAPI discovered that 176 of 238 new accounts were bots that bypassed three layers of protection including rate limiting and email verification. The issues stemmed from in-memory counters reset on every deployment, uvicorn trusting any X-Forwarded-For header, and email verification never being enforced in code. A full audit revealed additional flaws such as stored XSS via JSON-LD on public Q&A pages and an IDOR allowing any authenticated user to read all tasks in a project by supplying its ID. Fixes included moving rate limits to the database, properly extracting the client IP from the rightmost X-Forwarded-For entry, adding signed form timestamps, and escaping JSON for script contexts. The case highlights common pitfalls when deploying Python web services behind nginx without strict trust boundaries.