Listen to this Post
Introduction:
Bug bounty programs define clear perimeters to help researchers focus on in-scope assets. However, critical vulnerabilities often lurk on forgotten subdomains, API gateways, or shadow IT resources that fall outside the agreed scope. When ATTER Koffi Kallern, a Web Security Researcher holding CAPT and CWSE (in preparation) with CVE-2026-3695, discovered an exposed vulnerability on an out-of-scope subdomain during a French healthcare program on YesWeHack, he chose responsible disclosure directly to ANSSI, France’s national cybersecurity agency. This case highlights that security is not a box‑ticking exercise—ethical hackers must sometimes step beyond scope to protect the broader digital ecosystem.
Learning Objectives:
- Master subdomain reconnaissance techniques to uncover hidden attack surfaces, even those excluded from bug bounty scopes.
- Execute a responsible disclosure workflow when finding vulnerabilities on out‑of‑scope assets, including escalation to national CSIRTs like ANSSI.
- Apply mitigation strategies for healthcare APIs and cloud assets to prevent critical vulnerabilities from lingering outside monitored perimeters.
You Should Know:
- Advanced Subdomain Enumeration – Finding the Undisclosed Surface
Before any vulnerability assessment, you need a complete asset inventory. Standard DNS enumeration often misses subdomains that are not linked from public sources. Below are verified commands for Linux and Windows that automate discovery of subdomains—including those that might be out of scope but still exposed.
Linux (using subfinder, assetfinder, and amass):
Install tools (if not present) go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest go install -v github.com/tomnomnom/assetfinder@latest sudo apt install amass -y Enumerate subdomains for a target domain (e.g., healthcare-example.fr) subfinder -d healthcare-example.fr -o subdomains.txt assetfinder --subs-only healthcare-example.fr >> subdomains.txt amass enum -passive -d healthcare-example.fr -o amass_output.txt Resolve live hosts and filter by HTTP/HTTPS cat subdomains.txt | httpx -silent -status-code -title -o live_hosts.txt
Windows (PowerShell with dnscan and nslookup):
Download dnscan (DNS brute-force) from GitHub
git clone https://github.com/dnscan/dnscan.git
cd dnscan
Use a wordlist for subdomain brute-force
python dnscan.py -d healthcare-example.fr -w subdomains.txt -o windows_subs.txt
Resolve using nslookup in a loop
Get-Content windows_subs.txt | ForEach-Object {
try {
$result = Resolve-DnsName $_ -ErrorAction Stop
Write-Host "$_ -> $($result.IPAddress)"
} catch { }
}
Step‑by‑step guide:
- Collect all known subdomains via passive sources (certificate transparency, DNS history).
- Perform active brute‑force using a curated wordlist (e.g., 2M‑entry SecLists).
- Use `httpx` or `curl` to identify live web services.
- Compare results against the bug bounty scope document. Any uncovered subdomain that responds with HTTP 200/403/500 is a candidate for further testing—even if officially “out of scope,” it represents a real risk to the organization.
2. Vulnerability Identification on Out‑of‑Scope Assets
Once you find an unexpected subdomain, treat it as a potential entry point. In the healthcare case, the researcher identified a critical vulnerability—likely an authentication bypass, sensitive data exposure, or RCE—on a subdomain not listed in the program. Below are common checks and commands to confirm severity.
Check for exposed configuration files and directories:
Use gobuster for directory brute-force gobuster dir -u https://out-of-scope-subdomain.healthcare-example.fr -w /usr/share/wordlists/dirb/common.txt -t 50 Test for common API endpoints ffuf -u https://out-of-scope-subdomain.healthcare-example.fr/FUZZ -w api-endpoints.txt -fc 404
Testing for misconfigured cloud storage (AWS S3 open bucket):
Install awscli and test anonymous access aws s3 ls s3://out-of-scope-bucket-1ame --1o-sign-request If successful, bucket is publicly readable – a critical data leak.
Linux command to check for default credentials on healthcare APIs:
Example: test for default admin:admin on API login
curl -X POST https://out-of-scope-subdomain/api/login -H "Content-Type: application/json" -d '{"username":"admin","password":"admin"}' -v
Step‑by‑step guide:
- Run passive reconnaissance to map all HTTP/HTTPS services on the asset.
- Test for OWASP Top‑10 vulnerabilities (SQLi, XSS, IDOR) using tools like Nuclei or manual Burp Suite.
- If vulnerability is confirmed, document with screenshots, request/response payloads, and impact assessment.
- Crucially, check the bug bounty scope statement again. If the asset is excluded, do not submit through the platform’s standard channel—proceed to responsible disclosure (next section).
3. Responsible Disclosure to National CSIRT (ANSSI)
When a vulnerability falls outside a bug bounty scope but still affects a critical sector (healthcare, finance, energy), reporting it to the national CERT/CSIRT is a professional and ethical path. ANSSI provides a secure channel for such reports.
Step‑by‑step guide to report to ANSSI (or any national CSIRT):
1. Prepare a encrypted report using PGP/GPG. ANSSI’s PGP key is available on their website.
Generate a report.txt file and encrypt it gpg --output report_encrypted.gpg --encrypt --recipient "ANSSI PGP Key ID" report.txt
2. Include the following in your report:
- Description of the vulnerability (including CVSS score).
- Steps to reproduce with proof-of-concept (PoC) code or screenshots.
- The out‑of‑scope subdomain URL and the parent organization (French healthcare entity).
- Your public key for encrypted replies.
- Send via official reporting channel – ANSSI accepts reports at
[email protected]. Use encrypted email. - Request a CVE ID if the vulnerability affects multiple systems. The researcher already has CVE-2026-3695, demonstrating they know the process.
- Wait for acknowledgment – CSIRTs typically respond within 48‑72 hours. Do not disclose any details until a patch is released or the organization authorizes disclosure.
Why not disclose on public bug bounty platforms? Out‑of‑scope reports are often rejected or ignored by program owners because they lack contractual coverage. A national CSIRT has the authority to enforce remediation, especially for critical infrastructure.
- Leveraging Bug Bounty Platforms (YesWeHack) for Scope Negotiation
YesWeHack, the platform used in the original post, allows researchers to request scope expansions. After reporting to ANSSI, the researcher could also politely inform YesWeHack’s security team about the out‑of‑scope finding to encourage scope updates.
Suggested email template to a bug bounty platform:
Subject: Out-of-scope vulnerability disclosure - [Healthcare Program Name] Dear YesWeHack Security Team, During testing within the scope of [program name], I identified a subdomain [bash] not listed in the current scope. This subdomain exposes a critical vulnerability (details have been disclosed to ANSSI under reference [ANSSI ticket ID]). I recommend expanding the program scope to include this subdomain, as it contains [description of data/functionality]. I am available to assist with remediation verification once it is in scope. Thank you for your commitment to responsible disclosure.
Step‑by‑step guide:
- Never share PoC or sensitive details with the platform if the asset is out of scope – that could violate the program’s terms.
- Instead, share only the domain name and a high‑level risk summary.
- Request that the program owner (healthcare organization) add the subdomain to the scope for future testing.
- If the organization refuses, continue to work through the CSIRT for enforcement.
-
Mitigation Strategies for Healthcare APIs and Cloud Hardening
To prevent vulnerabilities from persisting on forgotten subdomains, healthcare organizations must implement continuous asset discovery and cloud hardening.
API Security – Validate JWT tokens and rate limiting:
Example NGINX config for API gateway with strict JWT validation
location /api/ {
auth_jwt "Healthcare API";
auth_jwt_key_file /etc/nginx/keys/public.pem;
limit_req zone=api burst=10 nodelay;
proxy_pass http://backend-api;
}
Cloud hardening – Block public access to storage buckets (AWS CLI):
Remove public ACL from all buckets aws s3api put-bucket-acl --bucket healthcare-bucket-1ame --acl private Enforce bucket policy denying public access aws s3api put-public-access-block --bucket healthcare-bucket-1ame --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Linux command to continuously monitor for new subdomains (cron job):
Add to crontab - every 6 hours 0 /6 /home/security/subfinder -d healthcare-example.fr -o /var/log/new_subs_$(date +\%Y\%m\%d_\%H\%M).txt
Step‑by‑step guide for defenders:
- Implement a shadow IT discovery program using tools like Shodan, Censys, and internal DNS logs.
- Require all subdomains to register in a CMDB with a responsible owner.
- Run automated vulnerability scanners (Nessus, OpenVAS) against all discovered assets, regardless of their official “scope”.
- Establish a bug bounty agreement that includes a “graceful out‑of‑scope” clause – allowing researchers to report without fear of legal action, similar to safe harbor laws.
-
Legal and Ethical Boundaries – Staying Safe When Going Out of Scope
Even with responsible disclosure to ANSSI, researchers must understand legal risks. In many countries, testing out‑of‑scope assets can violate computer fraud laws (e.g., CFAA in the US, Loi Godfrain in France). However, French law ( 323-3-1 of the Penal Code) provides an exception for security researchers acting in good faith and reporting to ANSSI.
Safe practices:
- Stop testing immediately after identifying the vulnerability – do not exfiltrate data.
- Document only what is necessary for the report.
- Use a separate testing environment (VPN, isolated VM) to avoid contamination.
- Never exploit the vulnerability beyond proof-of-concept (e.g., no ransomware or data modification).
Example of a safe PoC command (non‑destructive):
Instead of deleting data, use a benign GET request to confirm IDOR curl -H "Authorization: Bearer $TOKEN" https://out-of-scope-subdomain/api/patient/1234 If you see another patient's data, stop immediately and record the response.
Step‑by‑step guide:
- Before testing any asset, check the organization’s responsible disclosure policy or safe harbor statement.
- If none exists, limit your testing to passive reconnaissance only (DNS lookups, certificate logs).
- If you accidentally stumble upon a vulnerability without active scanning (e.g., while browsing), you are typically protected.
- Always report through ANSSI or a national CERT – they can provide legal protection certificates if needed.
What Undercode Say:
- Key Takeaway 1: Out‑of‑scope vulnerabilities are not “someone else’s problem.” The French healthcare case proves that ethical hackers must escalate through national CSIRTs when bug bounty programs fail to cover critical assets.
- Key Takeaway 2: Responsible disclosure is a process, not a single email. It requires encrypted communication, proof‑of‑concept without damage, and patience – but it strengthens the entire digital ecosystem.
Analysis: ATTER Koffi Kallern’s approach demonstrates maturity beyond typical bug bounty hunting. By choosing ANSSI over ignoring the finding or publicly shaming the organization, he preserved trust and likely expedited remediation. The reference to CVE-2026-3695 suggests he has prior experience with formal vulnerability disclosure. Healthcare sectors are notoriously slow to patch, but CSIRT involvement adds regulatory pressure. The post also highlights a gap in bug bounty programs: many exclude subdomains that are still live and vulnerable. Platforms like YesWeHack should consider mandatory scanning of all subdomains belonging to the organization, not just those listed. This incident will likely push French healthcare providers to adopt continuous asset discovery. The ethical stance—security does not stop at a defined perimeter—should become industry standard. However, researchers must remain cautious of legal retaliation; ANSSI’s protection is robust but not universal. Overall, this is a textbook example of how to handle the gray area between scope and responsibility.
Prediction:
- -1 Out‑of‑scope vulnerabilities will become the primary attack vector for threat actors in 2026‑2027, as bug bounty programs inadvertently create blind spots by relying on self‑reported asset lists rather than automated discovery.
- +1 National CSIRTs like ANSSI will formalize “out‑of‑scope disclosure bounties,” paying researchers for vulnerabilities found on any asset owned by critical infrastructure operators, regardless of bug bounty scope.
- -1 Healthcare organizations will face regulatory fines from GDPR and French data protection authorities if they continue to leave subdomains unmonitored; the ANSSI report in this case may trigger an audit.
- +1 Bug bounty platforms (YesWeHack, HackerOne) will introduce mandatory “full organizational discovery” tiers, where programs automatically include all resolvable subdomains unless explicitly excluded by legal reasons.
- -1 Some researchers will abuse out‑of‑scope findings by extorting organizations directly instead of following responsible disclosure, leading to stricter anti‑hacking laws that could criminalize good‑faith testing.
- +1 The combination of CVE-2026-3695 and this ANSSI disclosure will be cited as a case study in future CWSE and CAPT training courses, setting a new ethical standard for European bug bounty hunters.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Atter Koffi – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
