PS5 research advances through separate discoveries, implementations and ports. A timeline helps explain why a useful older guide can now have the wrong host, port or capability assumptions. Use primary researcher disclosures and project source to identify which claim was actually demonstrated.
Reviewed 10 October 2026. Milestones below identify public documentation or repositories; repository creation dates are not automatically vulnerability discovery or first-release dates.
Public research milestones
| Period | Primary evidence | Why it matters |
|---|---|---|
| 2022: BD-J work | TheFlow's BD-J project and psxdev's PS5 reimplementation | Research into the optical-disc Java environment. psxdev records its initial public release on 18 June 2022. |
| 14 September 2022 | CTurt's mast1c0re Part 1 | Published emulator escape research; the author dates the underlying report to September 2021. Publication and discovery are different events. |
| 2022 onward | PS5 IPv6 repository | A public browser-based kernel primitive and documented PS5-specific security limitations. |
| 4 September 2024 | FreeBSD-SA-24:14.umtx | Upstream advisory for CVE-2024-43102, crediting Synacktiv. A reference-counting race in shared-memory mutex handling can produce a use-after-free. |
| 2024 | PS5 UMTX implementation and Byepervisor | Separate kernel and low-firmware hypervisor research. The latter links its hardwear.io NL 2024 presentation. |
| 2025–2026 | Y2JB, Luac0re and Remote Lua Loader | Alternative application hosts and native userland possibilities. Their kernel payload prerequisites remain separate. |
| 2026 | Relapse | New browser and kernel implementation with its own firmware gate; prior chain limits should not be silently applied to it. |
What an upstream advisory can establish
The FreeBSD advisory explains a race that removes a shared-memory mapping too many times, freeing an object prematurely. It establishes the upstream bug identity, correction date and affected FreeBSD branches. It does not list PS5 firmware, application entry points, console offsets or a finished homebrew environment. Those belong to the console implementation's documentation. This is why an upstream CVE range and a console firmware list must be cited separately.
Use a hierarchy of evidence
- Researcher disclosure: explains the bug, affected component and technical result. It can be excellent evidence for mechanism without being a beginner procedure.
- Maintained source and exact firmware gate: shows which revisions the implementation actually selects and rejects.
- Tagged releases: establish an intended downloadable build, changelog and the maintainer's stated support.
- Explicit test statement: ties a result to firmware, console, host and payload revisions. Retain those details.
- Issue reports: can expose regressions or edge cases but may omit prerequisites. Treat individual reports as observations, not a universal matrix.
This hierarchy is an editorial method, not a guarantee that a repository is trustworthy. Evaluate the content, provenance and reproducibility. A popular fork can bundle useful improvements while still carrying outdated documentation from its parent. A compilation success proves buildability; it does not prove execution on hardware.
Compare wording with code
A useful example is Relapse: its overview states a broad firmware interval, while the reviewed firmware gate selects individual releases. The matrix preserves those exact values. An SDK commit adding offsets, or a payload port adding a switch case, establishes a narrower fact than a complete exploit chain test. Keep claims at the level the evidence supports.
Also distinguish a feature menu from a functioning feature, an optional future-work item from released code, a kernel exploit from a hypervisor bypass and a patched entry environment from a stock console. These distinctions prevent a chain's convenient name from hiding incompatible prerequisites.
A reusable research record
For each update, save the source URL, repository owner, commit or release tag, source date, review date, exact claim, exact prerequisites and capability demonstrated. If a maintainer reports one tested firmware within a wider supported interval, record both. If sources disagree, identify their different revisions and implementations before choosing one. Keep caveats near the claim rather than in an unrelated footer.
The Relapse revision reviewed here is dd8e4e0914c5e9d066ee1f9b056be76cb992c8e0, dated 30 September 2026 in the public GitHub commit record. Preserve a pinned revision alongside a moving project homepage so future readers can reconstruct the evidence. Continue to troubleshooting for the equivalent record of a failed hardware session.