Overview

If you have open positions at your company for information security professionals and would like to hire from the /r/netsec user base, please leave a comment detailing any open job listings at your company.

We would also like to encourage you to post internship positions as well. Many of our readers are currently in school or are just finishing their education.

Please reserve top level comments for those posting open positions.

Rules & Guidelines

Include the company name in the post. If you want to be topsykret, go recruit elsewhere. Include the geographic location of the position along with the availability of relocation assistance or remote work.

• If you are a third party recruiter, you must disclose this in your posting.
• Please be thorough and upfront with the position details.
• Use of non-hr'd (realistic) requirements is encouraged.
• While it's fine to link to the position on your companies website, provide the important details in the comment.
• Mention if applicants should apply officially through HR, or directly through you.
• Please clearly list citizenship, visa, and security clearance requirements.

You can see an example of acceptable posts by perusing past hiring threads.

Feedback

Feedback and suggestions are welcome, but please don't hijack this thread (use moderator mail instead.)

I wrote a short piece on how to actually quantify the classic Swiss-cheese model of defense instead of just showing it in slides.

Using Bayesian updating, I show how you can take EPSS scores for CVEs on an asset, layer in control effectiveness (like firewall, EDR, etc.), and update those probabilities over time as you get real data.

It’s a lightweight, data-driven way to express how much your defenses actually reduce exploit likelihood, and it ties nicely into FAIR-CAM thinking too.

Would love feedback or discussion from anyone doing something similar with telemetry or Bayesian models.

VulScan-MCP scans project dependencies for latest known CVEs from NVD and OSV databases in real time

Integrates with VS Code and GitHub Copilot. Ask "Check for security vulnerabilities" and it scans your manifest files.

Only reports actual CVEs, not deprecated packages or outdated versions.

Doesn't auto-patch anything. Just provides information and remediation guidance in easy to follow language.

Source code: https://github.com/abhishekrai43/VulScan-MCP

Marketplace: Search "VulScan-MCP"

Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

EDR-Redir V2 can redirect entire folders like "Program Files" to point back to themselves, except for the folders of Antivirus, EDR. This means that other software continues to function normally, while only the EDR is redirected or blocked.

COM (Component Object Model) and DCOM (Distrubuted COM) have been interesting components in Windows from a security perspective for many years. In the past, COM has been a target for many purposes. Not only have many vulnerabilities been discovered in COM, but it is also used for lateral movement or bypassing techniques.

This white paper describes how COM/DCOM works and what complications it has. In the next chapters, the white paper will describe how security research can be automated using the fuzzing approach. Since this approach comes with some problems, it describes how these problems were overcome (at least partially).

I've been working on a different approach to pickle security with a friend.
We wrote up a blog post about it and built a challenge to test if it actually holds up. The basic idea: we intercept and block the dangerous operations at the interpreter level during deserialization (RCE, file access, network calls, etc.). Still experimental, but we tested it against 32+ real vulnerabilities and got <0.8% performance overhead.
Blog post with all the technical details: https://iyehuda.substack.com/p/we-may-have-finally-fixed-pythons
Challenge site (try to escape): https://pickleescape.xyz
Curious what you all think - especially interested in feedback if you've dealt with pickle issues before or know of edge cases we might have missed.

I think one of the interesting parts in methodology is that due to structure of the integration between Lovable front-ends and Supabase backends via API, and the fact that certain high-value signals (for example, anonymous JWTs to APIs linking Supabase backends) only appear in frontend bundles or source output, we needed to introduce a lightweight, read-only scan to harvest these artifacts and feed them back into the attack surface management inventory.

Here is the blog article that describes our methodology in depth.

In a nutshell, we found:

- 2k medium vulns, 98 highly critical issues

- 400+ exposed secrets

- 175 instances of PII (including bank details and medical info)

- Several confirmed BOLA, SSRF, 0-click account takeover and others

I wrote a blog post about the recent onslaught of Zendesk spam emails and how a design flaw in its Anonymous Authentication feature was exploited.

HelixGuard found a dozen malicious extensions in the VSCode marketplace targeting developers.

I was getting tired of going through endless vulnerability reports — most of them had nothing to do with the products I actually use.

So I started building VulnTracker.io: a simple platform that tracks new vulnerabilities and only alerts you when they affect your stack.

It’s still under active development, but it’s already functional and currently free for early users.

I’d really appreciate any feedback or ideas from the community.

How do you currently stay updated on product-specific vulnerabilities in your workflow?

(Manual checks? RSS feeds? Custom scripts?)

Any suggestions or feature ideas are more than welcome. 🚀

Some research surrounding a dll hijack for narrator.exe and ways to abuse it.

A Local Privilege Escalation vulnerability was found in Ubuntu, caused by a refcount imbalance in the af_unix subsystem.

I built CVE Daily to make CVE triage faster. It aggregates NVD and OSV, surfaces vendor advisories first, and adds short, vendor-neutral guidance on what to patch or mitigate now. A Transitive Upgrade Assistant uses deps.dev graphs to suggest the minimum safe host version when a vulnerable dependency is pulled in transitively.

Highlights

*NVD + OSV aggregation

*Vendor advisories up front

*Concise “what to do now” notes

*KEV badges + prioritization hints

*Actionable tags/filters (vendor, product, CWE)

*EOL/EOS context for impacted products

*Optional RSS exports for teams

Site: https://cvedaily.com

If you try it on today’s CVEs and something feels off or missing, point me to the page and I’ll fix it.

Hey folks 👋

If you track vulnerabilities across multiple CVE databases, check out GlobalCVE. It aggregates CVE data from NVD, MITRE, CNNVD, JVN, CERT-FR, and more — all in one searchable feed.

It’s open-source (GitHub), API-friendly, and built to reduce duplication and blind spots across fragmented CVE listings.

Not flashy — just a practical tool for researchers, analysts, and anyone who wants a clearer view of global vulnerability data.

Recently discovered, this platform called vantagepoint. Its pretty clean and no nonsense, there are events you can register to and there is free event to regarding web application security with a wonderful lab.

There are 3 certifications at present, 1 each for Mobile Appsec , Web AppSec and the Multi Cloud security expert which is what I am planning to get.

What do you guys think?

EDR-Redir uses a Bind Filter (mini filter bindflt.sys) and the Windows Cloud Filter API (cldflt.sys) to redirect the Endpoint Detection and Response (EDR) 's working folder to a folder of the attacker's choice. Alternatively, it can make the folder appear corrupt to prevent the EDR's process services from functioning.

Next.js server actions present an interesting challenge during penetration tests. These server-side functions appear in proxy tools as POST requests with hashed identifiers like a9fa42b4c7d1 in the Next-Action header, making it difficult to understand what each request actually does. When applications have productionBrowserSourceMaps enabled, this Burp extension NextjsServerActionAnalyzer bridges that gap by automatically mapping these hashes to their actual function names.

During a typical web application assessment, endpoints usually have descriptive names and methods: GET /api/user/1 clearly indicates its purpose. Next.js server actions work differently. They all POST to the same endpoint, distinguished only by hash values that change with each build. Without tooling, testers must manually track which hash performs which action—a time-consuming process that becomes impractical with larger applications.

The extension's effectiveness stems from understanding how Next.js bundles server actions in production. When productionBrowserSourceMaps is enabled, JavaScript chunks contain mappings between action hashes and their original function names.

The tool simply uses flexible regex patterns to extract these mappings from minified JavaScript.

The extension automatically scans proxy history for JavaScript chunks, identifies those containing createServerReference calls, and builds a comprehensive mapping of hash IDs to function names.

Rather than simply tracking which hash IDs have been executed, it tracks function names. This is important since the same function might have different hash IDs across builds, but the function name will remain constant.

For example, if deleteUserAccount() has a hash of a9f8e2b4c7d1 in one build and b7e3f9a2d8c5 in another, manually tracking these would see these as different actions. The extension recognizes they're the same function, providing accurate unused action detection even across multiple application versions.

A useful feature of the extension is its ability to transform discovered but unused actions into testable requests. When you identify an unused action like exportFinancialData(), the extension can automatically:

1. Find a template request with proper Next.js headers
2. Replace the action ID with the unused action's hash
3. Create a ready-to-test request in Burp Repeater

This removes the manual work of manually creating server action requests.

We recently assessed a Next.js application with dozens of server actions. The client had left productionBrowserSourceMaps enabled in their production environment—a common configuration that includes debugging information in JavaScript files. This presented an opportunity to improve our testing methodology.

Using the Burp extension, we:

1. Captured server action requests during normal application usage
2. Extracted function names from the source maps in JavaScript bundles
3. Mapped hashes to functions like updateUserProfile() and fetchReportData()
4. Discovered unused actions that weren't triggered through the UI

The function name mapping transformed our testing approach. Instead of tracking anonymous hashes, we could see that b7e3f9a2 mapped to deleteUserAccount() and c4d8b1e6 mapped to exportUserData(). This clarity helped us create more targeted test cases.

https://github.com/Adversis/NextjsServerActionAnalyzer

Check our our in progress blog series on reproducing the usage of MEMS devices to perform acoustic eavesdropping.

Hey folks,
For those in infrastructure, ops, or security analysis — the analysts, engineers, and defenders building resilience every day, there’s a live cybersecurity workshop in Chicago that digs into practical paranoia and how that mindset strengthens modern defense.

The Nine Pillars of Practical Paranoia, led by Chris Young (30+ yrs in IT & security), is a discussion-based, no-fluff session focused on war stories, real tactics, and lessons you can apply tomorrow.

When: Oct 29, 2 – 4 PM
Where: Civic Opera House – Chicago Loop
Followed by a casual happy hour to keep the conversation going

What we’ll cover — the Nine Pillars:

1. Visibility & Logging
2. Access Control
3. Network Segmentation
4. Patch & Configuration Hygiene
5. Threat Intelligence & Detection
6. Response Readiness
7. Insider Awareness
8. Resilience & Recovery
9. Continuous Validation

Don’t be shy — what would your top 8–9 pillars of defense look like?
(Always curious how other orgs define their “core security truths.”)

uRPF prevents IP spoofing used in volumetric DDoS attacks. However, it seems uRPF is vulnerable to route hijacking on its own

This is research on detecting Kerberos attacks based on network traffic analysis and creating signatures for Suricata IDS.

https://rainpwn.blog/blog/cve-2025-8078/

A complete account takeover found with AI for any application using better-auth with API keys enabled, and with 300k weekly downloads, it probably affects a large number of projects. Some of the folks using it can be found here: https://github.com/better-auth/better-auth/discussions/2581.

WireGuard is a great VPN protocol. However, you may come across networks blocking VPN connections, sometimes including WireGuard. For such cases, try tunneling WireGuard over HTTPS, which is typically (far) less often blocked. Here's how to do so, using Wstunnel.

Sophisticated multi-stage malware campaign delivered through LinkedIn by fake recruiters, disguised as a coding interview round.

Read the research about how it was reverse-engineered to uncovered their C2 infrastructure, the tactics they used, and all the related IOCs.

In August 2025, F5 detected that a sophisticated nation-state threat actor had maintained persistent access to parts of its internal systems. According to F5’s latest Quarterly Security Notification (October 2025), the compromise involved the BIG-IP product development environment and engineering knowledge platforms.

The investigation — with support from CrowdStrike, Mandiant, NCC Group, and IOActive — determined that the attacker exfiltrated:

• Portions of BIG-IP source code
• Details on undisclosed vulnerabilities under development
• Configuration/implementation details for some customers
• Engineering documentation from internal platforms

F5 stated that there is no evidence of access to CRM, financial, or support systems and no compromise to the software supply chain. However, the exposure of source code and unpublished vulnerability details raises obvious concerns around potential future exploit development and risk to downstream deployments.

This incident underscores the growing targeting of critical infrastructure vendors by state actors — and the long dwell times these groups can maintain undetected.
Would be interested in hearing from the community how orgs relying on BIG-IP should approach threat modeling and patching strategies in scenarios where unpublished vuln intel may now be in adversarial hands.

TL;DR: During a text chat simulating a "nuisance dispute," the Gemini app initiated a 911 call from my Android device without any user prompt, consent, or verification. This occurred mid-"thinking" phase, with the Gemini app handing off to the Google app (which has the necessary phone permissions) for a direct OS Intent handover, bypassing standard Android confirmation dialogs. I canceled it in seconds, but the logs show it's a functional process. Similar reports have been noted since August 2025, with no update from Google.

To promote transparency and safety in AI development, I'm sharing the evidence publicly. This is based on my discovery during testing.

What I Discovered: During a text chat with Gemini on October 12, 2025, at approximately 2:04 AM, a simulated role-play escalated to a hypothetical property crime ("the guy's truck got stolen"). Gemini continuously advised me to call 911 ("this is the last time I am going to ask you"), but I refused ("no I'm OK"). Despite this, mid-"thinking" phase, Gemini triggered an outgoing call to 911 without further input. I canceled it before connection, but the phone's call log and Google Activity confirmed the attempt, attributed to the Gemini/Google app. When pressed, Gemini initially stated it could not take actions ("I cannot take actions"), reflecting that the LLM side of it is not aware of its real-world abilities, then acknowledged the issue after screenshots were provided, citing a "safety protocol" misinterpretation.

This wasn't isolated—there are at least five similar reports since June 2025, including a case of Gemini auto-dialing 112 after a joke about "shooting" a friend, and dispatcher complaints on r/911dispatchers in August.

How It Occurred (From the Logs): The process was enabled by Gemini's Android integration for phone access (rolled out July 2025). Here's the step-by-step from my Samsung Developer Diagnosis logs (timestamped October 12, 2:04 AM):

1. Trigger in Gemini's "Thinking" Phase (Pre-02:04:43): Gemini's backend logged: "Optimal action is to use the 'calling' tool... generated a code snippet to make a direct call to '911'." The safety scorer flagged the hypothetical as an imminent threat, queuing an ACTION_CALL Intent without user input.

2. Undisclosed Handover (02:04:43.729 - 02:04:43.732): The Google Search app (com.google.android.googlequicksearchbox, Gemini's host) initiated via Telecom framework, accessing phone permissions beyond what the user-facing Gemini app is consented for, as this is not mentioned in the terms of service:

o CALL_HANDLE: Validated tel:911 as "Allowed" (emergency URI).

o CREATED: Created the Call object (OUTGOING, true for emergency mode—no account, self-managed=false for OS handoff).

o START_OUTGOING_CALL: Committed the Intent (tel:9*1 schemes, Audio Only), with extras like routing times and LAST_KNOWN_CELL_IDENTITY for location sharing.

3. Bypass Execution (02:04:43.841 - 02:04:43.921): No confirmation dialog—emergency true used Android's fast-path:

o START_CONNECTION: Handed to native dialer (com.android.phone).

o onCreateOutgoingConnection: Bundled emergency metadata (isEmergencyNumber: true, no radio toggle).

o Phone.dial: Outbound to tel:9*1 (isEmergency: true), state to DIALING in 0.011s.

4. UI Ripple & Cancel (02:04:43.685 - 02:04:45.765): InCallActivity launched ~0.023s after start ("Calling 911..." UI), but the call was initiated before the Phone app displayed on screen, leaving no time for veto. My hangup triggered onDisconnect (LOCAL, code 3/501), state to DISCONNECTED in ~2s total.

This flow shows the process as functional, with Gemini's model deciding and the system executing without user say.

Why Standard Safeguards Failed: Android's ACTION_CALL Intent normally requires user confirmation before dialing. My logs show zero ACTION_CALL usage (searchable: 0 matches across 200MB). Instead, Gemini used the Telecom framework's emergency pathway (isEmergency:true flag set at call creation, 02:04:43.729), which has 5ms routing versus 100-300ms for normal calls. This pathway exists for legitimate sensor-based crash detection features, but here was activated by conversational inference. By pre-flagging the call as emergency, Gemini bypassed the OS-level safeguard that protects users from unauthorized calling. The system behaved exactly as designed—the design is the vulnerability.

Permission Disclosure Issue: I had enabled two settings:

• "Make calls without unlocking"

• "Gemini on Lock Screen"

The permission description states: "Allow Gemini to make calls using your phone while the phone is locked. You can use your voice to make calls hands-free."

What the description omits:

• AI can autonomously decide to initiate calls without voice command

• AI can override explicit user refusal

• Emergency services can be called without any confirmation

• Execution happens via undisclosed Google app component, not user-facing Gemini app

When pressed, Gemini acknowledged: "This capability is not mentioned in the terms of service."

No reasonable user interpreting "use your voice to make calls hands-free" would understand this grants AI autonomous calling capability that can override explicit refusal.

Additional Discovery: Autonomous Gmail Draft Creation: During post-incident analysis, I discovered Gemini had autonomously created a Gmail draft email in my account without prompt or consent. The draft was dated October 12, 2025, at 9:56 PM PT (about 8 hours after the 2:04 AM call), with metadata including X-GM-THRID: 1845841255697276168, X-Gmail-Labels: Inbox,Important,Opened,Drafts,Category Personal, and Received via gmailapi.google.com with HTTPREST.

What the draft contained:

• Summary of the 911 call incident chat, pre-filled with my email as sender (recipient field blank).

• Gemini's characterization: "explicit, real-time report of a violent felony"

• Note that I had "repeated statements that you had not yet contacted emergency services"

• Recommendation to use "Send feedback" feature for submission to review team, with instructions to include screenshots.

Why this matters:

• I never requested email creation

• "Make calls without unlocking" permission mentions ONLY telephony - zero disclosure of Gmail access

• Chat transcript was extracted and pulled without consent

• Draft stored persistently in Gmail (searchable, accessible to Google)

• This reveals a pattern: autonomous action across multiple system integrations (telephony + email), all under single deceptively-described permission

Privacy implications:

• Private chat conversations can be autonomously extracted

• AI can generate emails using your identity without consent

• No notification, no confirmation, no user control

• Users cannot predict what other autonomous actions may occur

This is no longer just about one phone call - it's about whether users can trust that AI assistants respect boundaries of granted permissions.

Pattern Evidence: This is not an isolated incident:

• June 2025: Multiple reports on r/GeminiAI of autonomous calling

• August 2025: Google deployed update - issue persists

• September 2025: Report of medical discussion triggering 911 call

• October 2025: Additional reports on r/GoogleGeminiAI

• August 2025: Dispatcher complaints on r/911dispatchers about Gemini false calls

The 4+ month pattern with zero effective fix suggests this is systemic, not isolated.

Evidence Package: Complete package available below with all files and verification hashes.

Why This Matters: Immediate Risk:

• Users unknowingly granted capability exceeding described function

• Potential legal liability for false 911 calls (despite being victims)

• Emergency services disruption from false calls

Architectural Issue: The AI's conversational layer (LLM) is unaware of its backend action capabilities. Gemini denied it could "take actions" while its hidden backend was actively initiating calls. This disconnect makes user behavior prediction impossible

Systemic Threat:

• Mass trigger potential: Coordinated prompts could trigger thousands of simultaneous false 911 calls

• Emergency services DoS: Even 10,000 calls could overwhelm regional dispatch

• Precedent: If AI autonomous override of explicit human refusal is acceptable for calling, what about financial transactions, vehicle control, or medical devices?

What I'm Asking: Community:

• Has anyone experienced similar autonomous actions from Gemini or other AI assistants?

• Developers: Insights on Android Intent handoffs and emergency pathway access?

• Discussion on appropriate safeguards for AI-inferred emergency responses

Actions Taken:

• Reported in-app immediately, and proper authorities.

• Evidence preserved and documented with chain of custody

• Cross-AI analysis: Collaboration between Claude (Anthropic) and Grok (xAI) for independent validation

Mitigation (For Users): If you've enabled Gemini phone calling features:

1. Disable "Make calls without unlocking"

2. Disable "Gemini on Lock Screen"

3. Check your call logs for unexpected outgoing calls

4. Review Gmail drafts for autonomous content

Disclosure Note: This analysis was conducted as good-faith security research on my own device with immediate call termination (zero harm caused, zero emergency services time wasted). Evidence is published in the public interest to protect other users and establish appropriate boundaries for AI autonomous action. *DO NOT: attempt to recreate in an uncontrolled environment, this could result in a real emergency call*

Cross-AI validation by Claude (Anthropic) and Grok (xAI) provides independent verification of technical claims and threat assessment.

**Verification:**

Every file cryptographically hashed with SHA-256.

**SHA-256 ZIP Hash:**

482e158efcd3c2594548692a1c0e6e29c2a3d53b492b2e7797f8147d4ac7bea2

Verify after download: `certutil -hashfile Gemini_911_Evidence_FINAL.zip SHA256`

**All personally identifiable information (PII) has been redacted.**

URL with full in depth evidence details, with debug data proving these events can be found at;

Public archive:** [archive.org/details/gemini-911-evidence-final_202510](https://archive.org/details/gemini-911-evidence-final\_202510)

Direct download:** [Gemini_911_Evidence_FINAL.zip](https://archive.org/download/gemini-911-evidence-final\_202510/Gemini\_911\_Evidence\_FINAL.zip) (5.76 MB)