When “Vulnerable” Isn’t Vulnerable: A False Positive in Nuclei External Interaction Checks

 

In November 2025, I came across an interesting behavior while using Nuclei—one that highlights an important lesson in application security: not every finding is a real vulnerability.

This write-up documents a false positive scenario I reported, how it happens, and why understanding your tools is just as important as running them.

The Scenario

While testing for external service interaction (commonly used in detecting SSRF or out-of-band vulnerabilities), I used the template:

external-service-interaction.yaml

The expectation was straightforward:

• The target application should trigger an outbound request
• That request should hit an OOB (out-of-band) service like Interactsh
• If observed → potential vulnerability

However, the results didn’t align with that assumption.

The Unexpected Behavior

The scan returned:

[info] external-service-interaction

At first glance, this suggests that:

• The target server made an outbound request
• The system might be vulnerable

But upon deeper inspection, that wasn’t actually happening.

What Was Really Happening

Instead of the target initiating the interaction, the behavior was caused by the scanner itself.

Here’s what the template effectively validated:

• The Interactsh service was reachable
• Nuclei could resolve the generated domain
• DNS/HTTP interaction occurred between the scanner and the OOB service

Crucially missing:

• No outbound request from the target server
• No real SSRF or external interaction vulnerability

This means the “positive” result could mislead testers into thinking a system is vulnerable when it isn’t.

Root Cause Insight

The issue stemmed from how DNS resolution and interaction checks were handled.

The template did not strictly validate whether:

• The interaction originated from the target
• Or from the scanning environment itself

Because of this, self-generated interactions could be interpreted as valid findings.

Reporting and Resolution

I reported this issue to the ProjectDiscovery team:

• Issue: https://github.com/projectdiscovery/nuclei/issues/6613

The response was quick and collaborative:

• The issue was reproduced
• A fix was proposed shortly after
• Patch introduced: skipping DNS lookups on Interactsh domains during checks
• Fix PR: https://github.com/projectdiscovery/nuclei/pull/6614

After testing the patch locally, the false positive no longer appeared.

Key Takeaways

1. Tools Can Mislead

Automated scanners are powerful—but they’re not infallible. Blind trust can lead to incorrect conclusions.

2. Validate the Source of Interaction

For OOB testing, always confirm:

• Who initiated the request?
• Is it truly coming from the target?

3. Understand Template Logic

Templates define behavior. A small logic gap can create large testing inaccuracies.

4. Debug Mode Is Your Friend

Running with:

-debug -vv

helped reveal what was actually happening behind the scenes.

Final Thoughts

This wasn’t a vulnerability in a target—it was a gap in detection logic. But addressing it improves the reliability of results for everyone using the tool.

Kudos to the ProjectDiscovery maintainers for the quick turnaround and fix.

False positives are often overlooked, but they matter. Reducing them improves signal quality—and ultimately, better security decisions.

The Golden Cookie: When SSO Session Boundaries Fail

Introduction 

During a private vulnerability disclosure engagement, I discovered a critical session management weakness affecting multiple internally developed, yet publicly accessible, web applications (18+ applications or more) within a single organization. 

At the center of the issue is a single authentication cookie “auth-cookie" — the Golden Cookie. 

Even though the cookie is set with Secure and HttpOnly flags, possession of this cookie alone allows cross-application authentication. 

I am fully aware that the organization has implemented SSO to enhance user experience. However, the implementation allows a single stolen cookie to immediately compromise active sessions, highlighting a systemic weakness compared to industry best practices. 

In accordance with my agreement with the affected organization, I cannot disclose any identifying details about the environment where this issue was found. This write-up focuses solely on the vulnerability class and its broader security implications.

Context 

• All applications rely on the same auth-cookie. 
• Cookie lifespan: 8 hours. 
• Secure and HttpOnly flags are present. 
• Logout on one device does not terminate other sessions using the same cookie value. 
• Best practices recommend: 
• Unique authentication cookie, should require a re-authenticate per device. 
• Scoped cookie per application. 
• Server-side revocation on logout. 
• Dependent session artifacts (cookies/headers) with different lifespans or renewal rules. 

Reproduction Steps 

Step 1 – Authenticate and Capture Cookies 

1. Log in on Device 1 with username, password, and MFA. 
2. Access other applications sharing with the SSO from another tab.
3. Intercept authentication response using a proxy tool. 
4. Identify all cookies issued example: 
• auth-cookie=XYZ123 
• session_meta=ABC456 
• tracking_id=DEF789 

 

Step 2 – Identify Authentication-Critical Cookie 

1. Using Burp Repeater, send requests to protected endpoints. 
2. Remove cookies one by one and resend the request. 
3. Observe which cookies are necessary to maintain a 200 OK response. 

Observation: 

Only one cookie is required which is the "auth-cookie". 

Step 3 – Parallel Session Injection 

1. Copy the "auth-cookie" value. 
2. In another device (Device 2), open a browser (e.g., Chrome). 
3. Insert the cookie manually. 
4. Access protected endpoints. 
5. Access other applications sharing with the SSO from another tab.
6. Do the same steps 1 to 5 on other browsers (e.g., Mozilla, Edge)

Observation: 

Device 2 authenticates immediately. Both Device 1 and Device 2 are now simultaneously authenticated including other applications sharing with the SSO. 

Step 4 – Logout Verification 

1. On Device 1, perform logout including other applications on other tabs. 
2. Refresh browsers on Device 2 to check if remains authenticated and if the value of "auth-cookie" is still the same. 

Observation: 

Device 2 sessions across applications remains authenticated using the same "auth-cookie" value. The session continues until the cookie expires (8 hours). 

Implication: 

If a stolen "auth-cookie" value is used immediately (pre-logout), an attacker can hijack an active session while the legitimate user remains logged in. When the user's logout on the original device, it does not globally revoke the same "auth-cookie" value. 

Real-World Exposure Scenarios 

Even with Secure and HttpOnly flags, cookies can be stolen via: 

• Social engineering + proxy interception: e.g., “anonymize your connection” campaigns where a user is tricked to import a malicious certificate and route traffic through a proxy controlled by the attacker. 
• Malware: automatically importing a malicious certificate and exfiltrating cookies. 
• TLS inspection misuse: insider or misconfigured proxy appliances capturing cookies.

Possession of a single "auth-cookie" allows full access across multiple applications. 

Security Implications 

• Concurrent sessions with shared cookie: a single compromised cookie allows cross-application authentication. 
• Insufficient logout invalidation: logging out on one device does not terminate other sessions. 
• Blast radius amplification: cookie works across 18+ applications or more. 
• Immediate exploitation risk: pre-logout cookie theft allows immediate takeover of active sessions. 

Recommended Remediation 

1. Should require re-authenticate per device.
2. Issue per-device unique session cookie. 
3. Enforce server-side authentication session revocation for all sessions on logout. 
4. Scope authentication cookie per application/service. 
5. Use dependent session artifacts with staggered lifespans or renewal requirements. 
6. Monitor and detect simultaneous reuse of identical cookie across devices. 

OWASP Alignment 

• A01:2021 – Broken Access Control – Single cookie provides broad unintended access. 
• A07:2021 – Identification & Authentication Failures – Active sessions persist after logout; stolen cookie enable account takeover. 

Severity Assessment 

CVSS v3.1: 9.4 (Critical) 

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L 

Justification: 

• Network (N): Exploitable entirely over the network once cookie is obtained. 
• Low Complexity (L): Requires only inserting the cookie in a browser or HTTP client. 
• Privileges Required (N): No existing account needed; cookie acquisition is separate (e.g., phishing, malware). 
• No User Interaction (N): Exploitation requires no further action. 
• Scope Changed (C): Access spans multiple distinct applications. 
• Confidentiality High (H): Sensitive data exposure. 
• Integrity High (H): Attacker can modify/delete data across applications. 
• Availability Low (L): Some resource disruption possible but secondary. 

Conclusion 

The Golden Cookie demonstrates that even well-designed SSO can be compromised if session isolation and logout enforcement are not properly implemented. 

Key lessons: 

• Do not rely solely from a single authentication cookie.
• A stolen single-valued cookie can immediately hijack active sessions. 
• Logout must revoke all sessions associated with that of authentication cookie value. 
• Scoped, per-device/session cookie with server-side revocation reduce risk. 
• Industry best practices mitigate the impact of cookie compromise across multiple applications. 

Update (April 2026):

This research has now been formally recognized and incorporated into the OWASP Web Security Testing Guide (WSTG). 

Github Repository: Testing Cross-Device Session Reuse and Single-Value Dependency in SSO

The contribution has been approved and merged, and is scheduled to be included in version 4.3 of the guide.

The testing approach described in this post has been adapted into an official WSTG test case to support security professionals in identifying similar session management weaknesses in their assessments.

As previously noted, specific organizational details remain undisclosed in accordance with responsible disclosure agreements.