Research Advisories

Security Advisories

Vulnerabilities discovered by the RedSecLabs research team, published after coordinated disclosure with the affected vendor.

We report first, publish second. Every advisory below was disclosed privately to the vendor and given time to remediate before publication, and each records the full timeline so the process is auditable.

If you have found a vulnerability in a RedSecLabs system, our reporting policy and contact details are on this page.

Coordinated
Disclosure model
90 days
Standard disclosure window
CVE
Requested where applicable
Public
Full timeline on every advisory

Published advisories

Advisories published by our research team. Historical disclosures by our founder predating RedSecLabs are listed for completeness and linked to their original sources.

ReferenceAffected productClassStatus
CVE-2014-6041Android Browser (AOSP) < 4.4Same-origin policy bypassFixed · disclosed
CVE-2015-3830Android stock browserAddress bar spoofingFixed · disclosed
CVE-2016-5267Firefox for AndroidAddress bar spoofingFixed · disclosed
2020 disclosure setMultiple mobile browsersAddress bar spoofingFixed · disclosed
RSL-2026-001Pending disclosure—Under coordinated disclosure

Historical entries are pre-RedSecLabs disclosures by our founder, included for provenance.

Our disclosure policy

How we handle vulnerabilities our researchers find in third-party products.

1
Private report to the vendor
We contact the vendor through their published security channel with a technical description, a reproducible proof of concept and an impact assessment. Where no channel exists, we approach a national CERT to broker contact.
2
Ninety-day standard window
Vendors get 90 days from acknowledgement to remediate before we publish. We extend this where a fix is genuinely in progress and complex, and we will publish sooner if a vulnerability is already being exploited.
3
Coordinated CVE assignment
Where the issue warrants it we request a CVE through the appropriate CNA, so the industry has a durable identifier and downstream users can track their exposure.
4
Publication with full timeline
The advisory publishes after a fix is available, including the complete disclosure timeline and vendor response. We do not publish weaponised exploit code.
5
No publication without remediation, except in the public interest
If a vendor does not remediate and users remain at material risk, we may publish with mitigations and without exploit detail, so affected users can defend themselves.

Reporting a vulnerability to RedSecLabs

If you believe you have found a security issue in a RedSecLabs system or service, we want to hear from you.

Email our security team through the contact form, marking the message for security disclosure
Include reproduction steps, affected URL or system, and an impact assessment
Give us a reasonable window to investigate and remediate before public disclosure
Do not access, modify or exfiltrate data belonging to us or our clients
Do not run denial-of-service, spam or social-engineering tests against our staff or systems
We will acknowledge your report, keep you updated, and credit you publicly if you would like

Have You Found Something?

Report it to our security team. We acknowledge every report and will credit you on the advisory if you would like us to.

Report a Vulnerability Our Research Lead

Where to next

Rafay Baloch

Founder, CEO and research lead

Research Lab

What our team is working on

AI & LLM Pentesting

Research-led AI security testing

Frequently Asked Questions

It is the practice of reporting a vulnerability privately to the affected vendor, giving them a reasonable period to develop and ship a fix, and only then publishing the technical details. It balances the vendor's need for time against users' right to know about risks affecting them. It is the model we follow for all research findings.

Ninety days from acknowledgement as standard. We extend that where a vendor is making genuine progress on a complex fix, and we may publish sooner if we have evidence the vulnerability is already being exploited in the wild, because at that point silence protects nobody but the attacker.

We publish enough technical detail for defenders to understand and mitigate the issue, including proof-of-concept detail where responsible. We do not publish weaponised, ready-to-run exploit code for vulnerabilities that remain widely unpatched.

Yes, if you would like us to. Tell us how you want to be credited when you report. You are equally welcome to remain anonymous.

We do not currently run a paid bounty programme for our own systems, but we do acknowledge and credit researchers who report responsibly. Contact us before testing anything that could affect availability.

Yes. We help organisations design vulnerability disclosure policies, set up intake and triage, and handle the coordination process, drawing on both sides of the experience, as reporters and as recipients.
📞 Call us Book a call