Blind XSS Accepted, No Payout: A Bug Bounty Lesson.

I discovered a Blind XSS vulnerability in a license application. The vulnerability was accepted by the bug bounty program, but the payout was withheld because my proof-of-concept payload collected information that the program considered a violation of its "report-first" policy.

Here's what happened.

The application allowed users to upload SVG and HTML files as proof of proficiency without proper server-side content sanitization.

The issue existed in Step 2 of the license application, where the upload functionality accepted multiple file formats, including HTML, SVG, XML, and several document and image types.

After upload, the backend emailed the original files as attachments to caseworkers responsible for reviewing applications.

This created the attack path: a malicious SVG could reach a staff member through an email attachment and execute embedded JavaScript when opened in the affected Microsoft Outlook rendering environment.

Proof of Concept

I tested the vulnerability with a live payload and received a callback from the staff member's Windows environment.

The execution context indicated that the SVG was rendered through Outlook's embedded browser component. This confirmed that the payload had executed in the intended context.

However, my payload did more than confirm execution. It collected information such as the visitor's IP address, Windows username, a screenshot, and other contextual details.

That decision ultimately affected the outcome of my report.

Accepted, But No Payout.

The program accepted the vulnerability but withheld the reward, explaining that the payload's data collection violated its "report-first" policy.

The finding itself was accepted, but the way I demonstrated its impact crossed a boundary defined by the program.

It was frustrating to confirm a vulnerability in a real-world execution context and still receive no payout. Nevertheless, the experience taught me an important distinction: proving that a vulnerability exists is not the same as being authorized to collect additional information from the affected system.

Root Cause and Remediation.

The vulnerability resulted from multiple security weaknesses:

• Insufficient server-side sanitization: SVG and HTML uploads were accepted without adequately neutralizing active content.
• Unsafe email attachment handling: Original user-uploaded files were forwarded directly to staff reviewers.
• Unsafe document rendering: The affected Outlook rendering environment executed JavaScript embedded in the SVG.
• Lack of safe document processing: Uploaded files were not converted into a format suitable for safe review before being emailed.

To address these issues, the organization should:

1. Validate and sanitize uploads server-side. Enforce an explicit allowlist of necessary file formats and use appropriate content validation. Reject active formats such as HTML and SVG if they are not required.
2. Avoid emailing untrusted files directly. Store uploads securely and provide staff with a controlled review mechanism.
3. Convert files to safe formats. Where practical, convert submitted documents into a safe, non-executable format before staff review.
4. Harden email and document handling. Configure supported systems to prevent active content from executing and avoid rendering untrusted files in privileged or sensitive contexts.
5. Apply defense in depth. Use malware scanning, restrictive content-serving policies, and appropriate isolation for document processing.

File extension checks alone are not sufficient. The organization must consider the actual file content and how downstream systems process it.

Lessons Learned

For Blind XSS, a minimal proof of execution is often enough.

A callback confirming JavaScript execution in the relevant context can demonstrate the vulnerability without collecting screenshots, usernames, or other sensitive information.

My key takeaways:

• Read the program's testing and reporting policies before crafting a payload.
• Collect only the minimum evidence necessary to prove the vulnerability.
• Avoid accessing or transmitting sensitive information unless explicitly authorized.
• Report the issue promptly when the program requires a report-first approach.
• Explain the potential impact clearly without unnecessarily expanding the proof of concept.

Final Thoughts

The vulnerability was real, and the report was accepted. But the payout outcome reminded me that technical success and responsible validation go hand in hand.

In bug bounty hunting, proving impact matters — but how you prove it matters just as much.

I hope you enjoyed this write-up and learned something from my experience. Until next time, keep learning, test responsibly, and stay blessed. 🙏🌾 https://x.com/ethical_h4ck3r_