Source-level vulnerability research I do outside of work, mostly against widely deployed
open-source C/C++ media software. Everything listed here is fixed and public — reported
upstream, patched, and shipped. Where I wrote the patch myself, I say so.
I keep this page as the canonical list because a finding that isn’t linkable isn’t
verifiable. Each entry points at the upstream pull request so you can read the actual
code, the maintainer’s review, and the commit that landed.
Upstream security fixes
Kodi — use-after-free in the texture cache
Class: Use-after-free (CWE-416) · Status: Fixed upstream, shipped in Kodi v22 “Piers”
· Patch author: me
Found a use-after-free in Kodi’s texture cache. I wrote the patch as well as the report,
and it was merged upstream and shipped in the v22 “Piers” release.
FFmpeg — use of uninitialized memory in the Escape 130 decoder
Class: Use of uninitialized memory (CWE-908) · Status: Fixed upstream, merged April 2026
· Credit: Found-by in the upstream commit
Use of uninitialized memory in FFmpeg’s Escape 130 decoder, in the old_y_avg path. I
reported it; the fix was merged upstream in April 2026 with a Found-by credit to me in
the commit message.
In progress
Additional reports are under coordinated disclosure and aren’t listed yet. They’ll show up
here once the vendor has shipped a fix and the embargo is done — not before.
How I disclose
When I find something in someone else’s code, I report it privately first and I don’t
publish until there’s a fix available. No deadline theatrics, no dropping details to make
a point. If a vendor is engaging in good faith I’ll wait as long as the work honestly
takes; if a vendor goes silent on something users are exposed to, I’ll say so publicly
before I say what the bug is.
Two things I try to hold to in write-ups: credit the people who did the work — including
the maintainers who fixed it — and don’t turn an install count into a victim count. Reach
is not impact.
Reporting a security issue to me
Full terms, scope and safe harbor: vulnerability disclosure policy.
If you’ve found a problem in this site, in csp-toolkit, or in anything else
I maintain, I want to hear about it.
Contact: carl.sampson@gmail.com — see/.well-known/security.txt for the machine-readable version.
Encryption: For anything sensitive, encrypt it to my PGP key. The key and its
fingerprint are on the GPG page.
What to include: what you did, what happened, and what you expected instead. A request
and response pair, or a short script, beats a scanner screenshot. If you’re not sure
whether something is a real finding, send it anyway — I’d rather read a false positive
than miss a real one.
What you can expect: an acknowledgement from me, a straight answer about whether I
think it’s a genuine issue, and credit in any write-up or commit unless you’d rather stay
anonymous. I don’t run a paid bounty, so I can’t offer money — I can offer a fast reply
and honest attribution.
What I’d ask of you: give me a reasonable chance to fix it before publishing, don’t
access or modify data that isn’t yours, and don’t degrade the service for anyone else.
Automated scanning against this site is fine; hammering it until it falls over is not.