HTB Browsed — Chrome-for-Testing Log Leak + Malicious Extens...

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://0xdf.gitlab.io/2026/03/28/htb-browsed.html
• Blog Title: HTB: Browsed — Chrome-for-Testing Log Leak + Malicious Extension SSRF → Localhost Flask → Bash Arithmetic Injection RCE → pycache .pyc Poisoning PrivEsc
• Suggested Section: Pentesting Web -> SSRF (add subsection: "SSRF via server-side headless browser / Chrome extension runners"), and Linux Privilege Escalation -> (new or existing) "Python pycache/.pyc poisoning"; optionally also Pentesting Web -> Command Injection -> "Bash arithmetic expansion/evaluation injection ($((...)))"

🎯 Content Summary

Title / Scenario

Browsed (HTB Linux) is a browser-extension “store” where users upload Chrome extensions (ZIPs). After upload, the backend runs the extension inside a headless “Chrome for Testing” instance and then returns the full verbose Chrome debug log output back to the uploader. This log output becomes a high-value information leak and, combined with the fact that attacker-controlled extension JavaScript executes during “testing”, enables a full chain to RCE and then ...

🔧 Technical Details

Chrome extension test runner as SSRF primitive: If an application accepts Chrome extension ZIP uploads and runs them in headless Chrome for “testing”, attacker-controlled extension code (notably a Manifest V3 background service worker) can execute server-side and perform arbitrary fetch() requests. This turns the test runner into an SSRF pivot capable of reaching internal DNS names and loopback-only services such as http://localhost/.

Mining verbose Chrome logs for internal attack surface: Returning headless Chrome verbose logs to untrusted users leaks sensitive environment details (DevTools listener like ws://127.0.0.1:PORT/devtools/browser/UUID, runtime paths such as /var/www/.cache/google-chrome-for-testing/..., and network traces like NetworkDelegate::NotifyBeforeURLRequest: http://localhost/). Attackers can use these artifacts to enumerate internal services and confirm SSRF reachability.

...

🤖 Agent Actions

I’m mapping the repo first and pulling the blog so I can place any addition in the right existing page rather than forcing a new one. After that I’ll read the closest HackTricks files for SSRF, command injection, and Python privilege escalation patterns before deciding what actually adds new value.
The repo already has good anchors for SSRF, command injection, browser extensions, and Python internals. I’m reading those now to determine whether one existing page can absorb the genuinely new material without duplicating coverage.
There’s no obvious existing Linux PE page dedicated to __pycache__ poisoning, so I’m checking the broader privilege-escalation index and Python-related pages before deciding whether that technique belongs there or is already covered elsewhere. The SSRF and command injection pages already exist, so those are still the strongest candidates if they have gaps.
I’ve confirmed one of the proposed additions is already partially documented: the command injection page already covers Bash arithmetic contexts. The remaining decision is between adding the newer SSRF pivot pattern or the missing Linux PE technique around writable __pycache__ and privileged imports.
I’ve narrowed it down to a single-file update in Linux privilege escalation. The .pyc/__pycache__ poisoning path is missing from HackTricks, while the Bash arithmetic injection already has coverage and the SSRF page would need a broader subsection to do it properly without violating the one-file constraint.
I’m editing the Linux privilege-escalation page now. The addition will stay narrowly scoped to privileged Python imports from writable __pycache__ directories, with enumeration, exploitation notes, and references, and I’ll leave the already-covered command injection material untouched.
The new section is in place and reads cleanly. I’m doing one last pass to trim a small code artifact in the PoC and then I’ll close with the exact file touched and the rationale for choosing only this technique.
Updated README.md with a new Linux privesc subsection covering writable __pycache__ / .pyc poisoning against sudo-allowed Python imports. It includes why the technique works, how to enumerate it, a concise abuse workflow, a minimal PoC shape, hardening notes, and references to the 2026-03-28 0xdf Browsed writeup plus Python primary sources.

I did not add the Bash arithmetic injection piece because command-injection.md already contains arithmetic-context coverage, and I kept the change to one file as requested. Verification passed with git diff --check and the inserted section reads cleanly in context.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://0xdf.gitlab.io/2026/03/28/htb-browsed.html

Content Categories: Based on the analysis, this content was categorized under "Pentesting Web -> SSRF (add subsection: "SSRF via server-side headless browser / Chrome extension runners"), and Linux Privilege Escalation -> (new or existing) "Python pycache/.pyc poisoning"; optionally also Pentesting Web -> Command Injection -> "Bash arithmetic expansion/evaluation injection ($((...)))"".

Repository Maintenance:

• MD Files Formatting: 963 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0