PS5 Firmware 14.10 Jailbreak Research: Inside Sony’s Kernel Defences, Failed ROP Exploits and the Search for Kernel Access

Sony’s PlayStation 5 firmware 14.10 is the target of a detailed kernel security research effort. An open-source project has mapped userland memory, probed hundreds of system-call behaviours and tested a number of possible information leaks. It has a working Lua-based research environment but no reliable kernel exploit. This article covers what the research establishes, why several promising techniques failed, and what would have to happen before firmware 14.10 could support a full jailbreak.

The PlayStation 5 hacking scene has spent years building exploit chains that turn browser vulnerabilities, game-level entry points and kernel bugs into ways of running unsigned code on Sony’s console. Every firmware release shifts the ground. A vulnerability that works on one version can vanish in the next, and a small restriction in the operating system can break an otherwise promising chain.

Firmware 14.10 is now the focus of an effort that shows how much work remains after the first foothold.

The public repository ZigZagBoi1/PS5-14.10-Research documents a systematic attempt to investigate the console’s kernel attack surface from a restricted game process. It does not present a single exploit as a finished jailbreak. It records individual probes, observed return values, memory layouts, syscall behaviour and hypotheses that either survived testing or were ruled out.

The project has built a userland research environment with access to a range of useful interfaces, and it found that some restrictions imposed by the Lua loader can be bypassed by calling system calls through a different wrapper. Neither result amounts to kernel compromise.

The latest research notes also correct several earlier readings. The proposed return-oriented programming execution path did not work as first believed. The suspected writable function pointer was never used by the syscall dispatcher. Attempts to recover kernel addresses through several system interfaces returned no useful pointers, and the tested asynchronous I/O interfaces stayed blocked. Together these corrections define where the investigation stands. ¹ ²

So, has the PS5 been jailbroken on firmware 14.10? Based on the repository’s published findings, no. What exists is a substantial investigation into the interfaces available from a sandboxed process, plus a search for a vulnerability that can bridge the gap between userland execution and kernel memory access.

The story is still worth telling. It shows why console exploitation rarely comes down to one bug, why a writable memory region is not automatically an exploit, and why researchers sometimes have to throw out an entire attack theory after a well-designed experiment shows the assumed execution path never existed.

PS5 firmware 14.10 jailbreak status: what has actually been demonstrated?

Three things need separating: a userland entry point, a kernel exploit and a complete jailbreak.

A userland entry point lets code run inside a process that would not normally run arbitrary code from the researcher. In the 14.10 project, the environment comes from a Lua 5.1 loader tied to a PlayStation 4-compatible game. The loader accepts research scripts, so the investigator can examine memory, call system interfaces and record the results.

A kernel exploit requires a vulnerability in privileged operating-system code, or some other capability that gives access to protected kernel memory or lets code run with kernel privileges. Calling a syscall does not do this. The kernel is built to accept requests from user processes while validating their arguments and enforcing the permissions of the caller.

A complete jailbreak goes further. Depending on the goal, it can require escaping the game sandbox, getting kernel read/write access, defeating further security restrictions, and setting up a reliable environment for unsigned applications or homebrew payloads.

The repository describes the first stage as available and the later stages as unresolved. Its latest research guide says there is no demonstrated native code execution through the investigated loader path and no successful defeat of kernel address-space layout randomisation (KASLR). ¹

Reports on the project should therefore not call firmware 14.10 jailbroken. The evidence supports a working userland research setup and a broad set of experiments. It does not support a finished kernel exploit.

Several findings looked more promising at first than they turned out to be. Researchers identified a large writable memory region, recovered the layout of loaded modules, catalogued machine-code gadgets and decoded the structure of a loader-associated ROP chain. Later tests showed that some of these were less useful than they appeared. A pointer can be writable without controlling execution. A system call can be reachable without being allowed to perform a privileged operation. A memory region can be executable with no way to transfer control into it. A kernel interface can return a large structure that contains no kernel addresses. The 14.10 campaign illustrates each of these.

Why the earlier PS5 jailbreaks matter

The history of PS5 exploitation explains why researchers are working through newer firmware so methodically.

Public jailbreaks have generally relied on chains of vulnerabilities. An initial bug gives code execution in a restricted environment, and further bugs provide memory access or privilege escalation until the researcher reaches the kernel or another protected component.

The exact chain depends on the firmware. A change to a browser engine, system library, kernel interface or sandbox policy can break a technique that used to work. A console can keep much of the same underlying code and still become far harder to exploit because one necessary assumption no longer holds.

The release of Relapse in September 2026 brought fresh attention to PS5 kernel exploitation. Contemporary reporting described compatibility with firmware versions 7.00 through 13.60. It matters to the 14.10 campaign as a reference point for techniques that worked against earlier versions of the operating system. ³

A public exploit for an earlier firmware does not tell us the same exploit works on 14.10. The entry point might be gone, a relevant syscall might be restricted, or the kernel might have changed how the vulnerable operation is implemented.

Asynchronous I/O (AIO) is the clearest case. The earlier exploitation landscape gave researchers a reason to ask whether a similar vulnerability class was still reachable on the newer firmware. The 14.10 project tested it and found nothing to revive the technique. Its current documentation records the tested AIO calls as process-terminating operations enforced at the kernel or sandbox level. ¹

Relapse is best read as a source of hypotheses. Its techniques can suggest which interfaces deserve investigation, but the newer firmware has to be tested independently, and reusing a syscall number, structure definition or exploit assumption from another release proves nothing about compatibility. That is also why a firmware-specific repository is useful before it contains a successful exploit: it records what happens on the target version.

From ROM keys to the kernel: three different parts of PS5 security

The 14.10 research sits alongside other developments in PlayStation security. Two earlier reports from The CyberSec Guru help show why different findings can attract similar headlines and have very different technical consequences.

The first is PS5 ROM Keys Leaked: Sony’s Unpatchable Security Nightmare, which covers reports about PlayStation 5 BootROM keys and what it means to expose secrets tied to the hardware root of trust. Those secrets matter at the earliest stage of the boot process and in verifying the software that follows.

The second is PS5 Jailbreak: PlayStation Store Can Be Redirected to a Custom URL to Launch a WebKit Jailbreak. It covers a demonstration on firmware 11.40 in which the PlayStation Store application was redirected to custom web content used as an entry point for a WebKit-based exploit chain.

Each report concerns a different layer of the console’s security architecture, and neither is evidence that the same vulnerability affects firmware 14.10. A BootROM-key disclosure involves secrets in the hardware-backed boot trust chain. A WebKit entry point involves code running in a browser-related environment. A kernel exploit involves privileged operating-system code. A hypervisor bypass involves yet another boundary, one that can stay in place even after the kernel is compromised.

What each could enable differs accordingly. A BootROM disclosure could help researchers analyse early boot components, depending on whether the material is authentic, how far it reaches and how usable it is. A WebKit vulnerability can give an initial foothold but does not grant kernel privileges. A kernel exploit can give privileged memory access without defeating the hypervisor’s protections.

The 14.10 campaign is about one transition: from a restricted userland process to kernel memory access. It does not show that BootROM keys can run unsigned software on this firmware, and it does not reuse the Store redirect as its entry point.

Console security headlines tend to fold several separate capabilities into the word “hacked”. For technical readers the useful questions are which boundary was crossed, on which firmware, and with what reproducible evidence.

A different kind of entry point: a game save and Lua 5.1

The 14.10 project gets its foothold from a game save and an embedded scripting environment, with no new browser vulnerability involved.

The repository identifies Hamidashi Creative, a Japanese visual novel with title ID CUSA27390, as part of the setup. The approach uses the game’s save-processing and scripting environment to establish Lua 5.1 execution inside the game process. A custom loader then accepts probe scripts over a local TCP connection on port 9026. ¹

A game-level weakness can give a stable research environment without compromising the operating system. A vulnerable save parser, an embedded interpreter or a loader that accepts external scripts may let a researcher run code inside the game, and that process can still be confined by the console’s sandbox.

Save files add their own problem. Console save data is not necessarily a plain file that can be edited and copied back. Depending on the platform and title, it may sit in an encrypted or authenticated container bound to a user account, and a modified save can be rejected if the integrity or account-binding checks fail.

For the 14.10 project, the part that counts is what follows a successful script execution. Once the loader accepts a probe, the investigator can run repeatable experiments without rediscovering the entry point each time. That is a big step up from a one-off crash. The environment can record return values, compare syscall behaviours and map the process’s virtual memory, and it lets the investigator isolate single assumptions. If a syscall fails, the next experiment can test whether the failure came from the Lua wrapper, the operating system or a bad argument.

Kernel research is largely about reducing uncertainty. A researcher may start with several explanations for a failed operation, and a carefully designed probe can rule some out and point to the next useful question.

The documentation describes a loader protocol in which each connection carries a length-prefixed Lua script, and the tooling records the output of each probe so the research can be organised into stages. ¹

The loader is a research component. An ordinary PS5 does not expose an unauthenticated service on port 9026, and the setup should not be mistaken for a vulnerability in Sony’s network services.

Why the Lua runtime complicates exploitation research

Lua 5.1 is a small, embeddable scripting language, and it was never designed for convenient 64-bit memory manipulation.

Numeric precision is one problem. Standard Lua 5.1 usually represents numbers as double-precision floating-point values. Those hold every integer exactly up to 2⁵³, but a 64-bit virtual address can be larger. Converting a pointer to an ordinary Lua number can lose precision and produce an address close to the intended one but not equal to it.

In low-level research that is dangerous. A corrupted pointer might land in an unmapped page, reference an unrelated object or kill the process. The repository therefore uses explicit 64-bit values for addresses that ordinary Lua numbers cannot hold safely. ¹

Error handling is another. Lua’s protected-call mechanism catches ordinary script errors and some failures exposed by the memory-access wrapper, but it cannot recover from a hardware fault that terminates the process. The repository reports that reading execute-only system-library pages can trigger a fatal fault even inside pcall.

The environment therefore cannot scan every address and treat every failure as recoverable. A probe has to tell apart a valid value, an ordinary API error and a process-ending memory fault. Output needs the same care: a function that returns an integer may have returned a real address, an error code, a sentinel or a value that only means something inside the loader.

These constraints look mundane next to kernel exploitation, but they decide whether the data a probe collects can be trusted.

Establishing the firmware’s identity and memory model

Before testing a possible vulnerability, researchers need to understand the environment it would run in.

The repository reports a target on PlayStation 5 firmware 14.10 with a FreeBSD-derived kernel identified as revision r230171. Its notes also record 16 KB virtual memory pages and a kern.securelevel value of 1024. These are observations from the tested environment, not independently verified specifications for every PS5 hardware revision or firmware installation. ¹

The FreeBSD lineage gives researchers a starting point for system calls, virtual memory, sockets, process structures and kernel subsystems. But the PS5 is not a stock FreeBSD server. Sony-specific changes, sandbox policy and hardware-backed protections can change how familiar interfaces behave.

The page size shows how. A 16 KB page holds four times as many bytes as a 4 KB page, so an allocation that fits in one page on a conventional system may span a different number of pages here. A buffer may be surrounded by different allocator metadata, several allocations may share a larger mapping, and a permission change can affect a bigger region than expected. A technique that depends on exact spacing between objects can fail when the allocation geometry differs from the environment it was developed in.

The securelevel value matters for a different reason. FreeBSD uses securelevel to restrict certain sensitive operations, but the number alone does not describe the full privilege model. The process sandbox, kernel policy and other platform-specific protections still apply, and a change to one setting would not mean every other restriction had been lifted.

Researchers need more than a kernel version string and a page size. They need to know which operations the process can perform, how those operations behave, which results can be trusted and which assumptions from other FreeBSD versions still hold. That baseline is the reference for every later experiment.

Userland ASLR: a significant discovery with a narrow scope

Address Space Layout Randomization (ASLR) changes where program components sit in virtual memory, so an attacker cannot reliably predict where useful code or data lives. A process has a main executable, shared libraries, a heap and a stack. If their locations change between launches, an exploit that relies on a fixed address can fail even though the code underneath is unchanged.

The 14.10 project reports that the Sony-specific dynlib_get_info interface, syscall 593, can return information about loaded userland modules. The repository says the probe recovered base information for 39 modules in the tested process. ¹ That lets researchers reconstruct the module layout instead of assuming a pointer seen in one run stays valid in the next.

The project also records per-connection changes in the address layout. Each new connection can create a fresh process context, so an address from an earlier session may no longer point to the same object, and probes cannot rely on hard-coded values.

Userland ASLR and kernel ASLR are separate problems, though. Knowing where a shared library is mapped says nothing about the kernel’s base address. The kernel has its own address space, and a userland pointer does not reveal privileged memory. Defeating kernel ASLR takes a genuine kernel pointer or a reliable side channel that gives equivalent information.

This is central to the project’s progress. The module information is a real userland capability, but it has not supplied the missing kernel address leak. The latest notes describe multiple attempts to obtain kernel pointers through system interfaces, and the tested paths produced nothing usable. ²

A value that looks like a pointer may not be one. Kernel structures can contain invalid-value markers, bitmasks or sanitised fields. A credible leak needs a value that corresponds to a real kernel object or code location and that the researcher can show is useful for the intended purpose. A userland ASLR bypass should not be presented as a KASLR bypass.

GPU-backed memory mappings: what a large writable region can and cannot do

The memory experiments also turned up a useful observation about GPU-related mappings.

The repository reports that a GPU-related allocation path gave the process a large contiguous region of readable and writable memory. Its notes describe at least 256 adjacent pages of 16 KB each, a nominal region of at least 4 MiB. ¹ A region that size is valuable for reverse engineering. It gives room to examine allocation boundaries, inspect data structures and test whether values can be modified, and a contiguous mapping is easier to interpret than a scatter of unrelated allocations.

A large writable mapping is still not an arbitrary read/write primitive across the system. Access to one region is different from being able to pick any address in the process or kernel and read or change it. A process can have full access to its own buffer and still be unable to touch protected pages elsewhere. Even when a region holds a pointer to an important object, writing a new value there guarantees nothing if the relevant code ignores the field, copies it elsewhere or validates it before use.

This mattered because the early heap experiments were used to investigate a loader-associated ROP structure. It appeared to contain a function pointer and argument slots that could be modified from the writable region, which looked like a possible route to controlled native execution. Later experiments showed that the assumed link between the structure and the syscall dispatcher was wrong. The memory was writable, but the modified fields did not control the path make_syscall() took. ² A writable region is a capability. Whether it becomes an exploit depends on what objects it holds, how they are used and whether an attacker can influence a security-sensitive operation through them.

Why /dev/dmem0 did not provide the expected shortcut

The project also investigated /dev/dmem0, an interface tied to the console’s memory architecture, to see whether it offered access to physical memory that ordinary virtual mappings hide.

The results indicate that the tested interface exposed a GPU-related memory aperture and not a route to CPU physical memory. Probing outside the accessible region returned unmapped or zero-filled results, which rules out the simple physical-memory route the researchers were testing. ³

The PS5’s CPU and GPU memory involve separate hardware and operating-system mechanisms, so an interface that exposes part of the graphics memory map does not grant access to privileged CPU memory. It also does not provide a way to inspect kernel page tables or bypass kernel restrictions. The experiment did set one boundary: the tested device interface did not give the direct physical-memory access that would have made kernel reconnaissance much easier.

W^X and execute-only memory: why readable code matters

Two memory protections feature heavily in the repository’s findings: Write XOR Execute (W^X) and execute-only memory (XOM).

W^X stops a memory region from being writable and executable at the same time, which makes it harder to inject machine code into a buffer and run it. A process may be able to allocate memory and fill it with arbitrary data while the operating system refuses to make that region executable.

The project reports that a mapping requested with read, write and execute permissions does not keep execute permission, and that attempts to enable execution through mprotect fail. That is consistent with strict separation between writable and executable memory. ¹

XOM adds a second obstacle. Some executable pages let the processor fetch instructions while blocking ordinary data reads of the same region, so a researcher may be able to run code from a page without being able to scan its bytes. The repository reports that system-library code pages are execute-only in the tested environment and that reading them can terminate the process. The main game executable, eboot, stayed readable and executable, so its code can be inspected. ²

This matters for return-oriented programming. A ROP chain reuses instruction sequences that already exist instead of injecting new ones, so researchers must find suitable sequences, understand their effects and establish a reliable way to move control between them. A gadget catalogue is useful reverse-engineering data, but finding gadgets is only one requirement. The exploit must also gain control of the instruction pointer and the relevant stack state, and the program must reach the chosen execution path.

The project appeared to make progress here. It catalogued gadgets in eboot and examined a loader-associated execution structure. Later tests showed the suspected chain was not used by the syscall wrapper. Readable executable code and a writable chain did not add up to a working control-flow primitive. ² W^X remains an obstacle, XOM restricts memory inspection, and the proposed execution mechanism has not been shown to work.

The syscall resolver finding: userland policy versus kernel policy

One of the more useful results concerns how the Lua loader exposes system calls.

A syscall resolver is a userland component that maps a name or number to an interface a script can invoke. It can reject a request before it ever reaches the operating system, so a failure at that stage does not mean the kernel lacks the syscall.

The repository found that a custom make_syscall(N) wrapper could invoke syscall numbers unavailable through the normal syscall.resolve() path. Its notes give sysctl, syscall 202 in the tested mapping, as an example: the resolver rejected it and the alternate wrapper reached it. ¹

This changes how earlier failures should be read. A probe that reports “blocked” may be describing the loader’s policy and not a kernel restriction, and the two have to be tested separately.

Reaching a syscall entry point is still different from being permitted to perform the operation. The kernel can validate arguments, check process credentials, apply sandbox restrictions or terminate the process when an operation is prohibited. The repository’s later tests bear this out. The alternate wrapper opened access to more interfaces, but it did not restore the blocked threading primitives or the tested AIO operations, and the documentation describes those as genuine restrictions and not resolver-side filtering. ¹

Counting successful calls is not enough in low-level research. Return values, side effects and security context all matter. A syscall that succeeds may return only ordinary process information, another may fail because the caller lacks permission, and a third may kill the process under an enforced policy. The resolver finding is a real research capability, but it is not a general sandbox escape or a kernel privilege escalation.

The ROP-chain theory that did not survive testing

The most revealing correction in the repository concerns the proposed ROP execution structure.

Early probes reported that a loader-associated chain, a function-pointer field called fn_addr and several argument slots could be modified through the writable memory region. The first interpretation was that the syscall mechanism used those fields to construct a native call. If that were right, changing the function pointer might have given controlled native execution.

Later experiments tested the assumption directly. Probe 45c compared the behaviour of the syscall wrapper under different modifications to the suspected function pointer and chain. The repository reports that replacing the pointer with an invalid address did not cause the expected fault, and that corrupting chain entries did not stop ordinary syscalls from completing. Most telling, the wrapper kept returning valid results even when the proposed function pointer was redirected to code that could not have performed the requested syscall. ²

Those results contradicted the original model. If the wrapper had been calling through the modified pointer, invalid targets or altered instructions should have changed its behaviour. It kept working independently of the chain.

The repository concluded that make_syscall() uses a C-level dispatch path and not the suspected ROP mechanism. The chain and pointer are still visible as data, but they do not control syscall execution as first believed, so the earlier claim of a working W^X bypass through this structure was withdrawn. ¹

A structure can look like a call frame, a field can hold something that resembles a code pointer, and the field can even be writable, without the program ever dereferencing it during the operation under study. The researcher has to show how the data relates to the real execution path, and when observed behaviour contradicts the model, the model has to change.

The follow-up work examined the Lua C-closure dispatch structure as another possible route to controlling execution. It found that the relevant C function pointer was read-only, although some neighbouring environment and upvalue fields could be modified. Those writable fields did not control the dispatcher. ²

Together these results close off the loader-dispatch route as originally understood. They do not prove native code execution is impossible through some other vulnerability, but this particular theory has not produced a working execution primitive.

Kernel KASLR: the missing link

Kernel address space layout randomisation is one of the major obstacles left in the 14.10 research. Even with some form of kernel memory corruption, an exploit may be unreliable if it cannot find where useful kernel code or data lives. A leak reduces that uncertainty only if it exposes a genuine address from the privileged address space.

The repository has explored several possible sources: routing sockets, kernel module interfaces, symbol lookup, process-information structures, kernel message buffers and memory-residency behaviour. The latest notes report that none provided a usable KASLR defeat. Routing-socket experiments produced no kernel pointers. Kernel module and symbol interfaces were blocked in the tested environment. Process-information structures held sanitised values and not usable kernel addresses, and the memory-residency tests did not produce the expected oracle. ¹ ²

Such negative results matter because a leak is only worth something if the information is real and relevant. A value that resembles a canonical kernel address may be a sentinel or a bitmask. A large structure may hold many fields and still omit the sensitive pointers. A syscall may succeed while returning information the caller already had.

The documentation explicitly warns against reading certain all-ones-style values as real kernel addresses, which guards against false positives. An apparent leak can otherwise lead to wrong calculations, wrong assumptions about kernel layout and time spent on a technique that never exposed privileged information.

The same caution applies to side channels. A memory-residency interface might in principle reveal which pages are mapped, but a useful KASLR oracle needs a consistent relationship between observable behaviour and the randomised layout. The tested mincore path did not deliver one.

As of the latest documented status, the project has not found a reliable kernel address leak, and that is the central gap between the current userland environment and a working kernel exploit.

Why the AIO route did not reopen the Relapse attack class

AIO was an obvious area to revisit because of its role in earlier PS5 exploitation. It lets operations be submitted for completion outside the immediate flow of the calling code, and its implementation involves kernel-managed state, queues and completion handling. In a vulnerable implementation, interactions between operations can create race conditions or expose unexpected state transitions.

The researchers first asked whether the apparent restriction came only from the Lua resolver. If so, reaching the syscall through the alternate wrapper might have changed the result. The latest notes record that the relevant AIO operations still caused immediate process termination when invoked through the raw syscall path, so the documentation treats the restriction as kernel- or sandbox-enforced and not a resolver limit. ¹ The standard resolver’s failure had left the interface’s usability open, and the raw-path experiments ruled out the straightforward bypass.

Thread creation raises a related problem. The repository reports that fork, rfork and thr_new remain blocked in the tested environment. Some race-condition exploits depend on coordinating several operations or threads so they overlap in a narrow timing window. A process that cannot create the needed concurrency may be unable to use such a technique even when the underlying kernel code is still present.

None of this proves that no AIO-related vulnerability can exist on newer firmware. It shows that the specific interfaces and conditions the project tested did not restore the earlier exploitation path. AIO was a sensible target, and the results did not demonstrate a revived Relapse exploit.

Networking: a large attack surface, but no confirmed kernel crash

The project also investigated the console’s networking stack, partly because network interfaces expose complex kernel code to attacker-controlled input. A packet passes through several layers of processing. The operating system parses headers, validates lengths, tracks protocol state, handles fragmentation and manages buffers, and a bug in any of those steps can cause memory corruption or an unexpected state transition.

The repository reports access to raw sockets and packet injection in the tested environment, along with experiments on IPv4 fragmentation, IPv6 extension headers, TCP state transitions, SCTP chunks and other protocol handlers. ² The documented probes report no kernel crashes from the tested malformed SCTP packets, IPv6 extension headers, TCP segments and IPv6 fragments. The project also reports that the tested socket-option handling clamps copy lengths and does not expose the suspected overflow. ¹

These results narrow the search but have to be read with care. A test that produces no crash shows only that the specific inputs and conditions did not trigger the failure. A parser may handle malformed input correctly in isolation and behave differently after a particular sequence of valid state transitions. A protocol may need an established connection before a deeper code path becomes reachable, and a timing-dependent issue may not appear in a short test.

Still, the record of negative results is useful. Investigators no longer have to assume every complex network parser is vulnerable. They can use the evidence to decide which hypotheses deserve more attention and which have become less promising.

What the Sony-specific syscalls reveal

The PS5 includes Sony-specific system interfaces on top of the FreeBSD-derived ones researchers will recognise. Their behaviour may not be explained by ordinary FreeBSD documentation. A syscall can accept a versioned structure, interpret fields under platform-specific rules or expose a service that does not exist in a standard operating-system build.

The 14.10 project has investigated the Sony-specific syscall range and documented several interfaces that respond to requests in the tested environment. Its latest notes include a survey of accessible Sony calls, but the tested output buffers revealed no usable kernel pointers. The documentation also identifies interfaces whose behaviour looked unusual and was later explained by predictable return values or resource metrics and not by an exploitable condition. ¹ ²

An unfamiliar syscall may return a positive value, modify a buffer or behave differently when passed a version field. That justifies further investigation, but it does not show a memory-safety bug or a privilege escalation path. A useful analysis works out what the call is meant to do, which arguments it accepts, how it handles malformed input and whether the observed behaviour breaks a security invariant. The project’s work on version-dependent return values fits that pattern. The behaviour looked odd, and it turned out to be a formula-based resource or version metric with no kernel pointer leak behind it.

The same goes for interfaces that accept buffers. A kernel write to a user-provided structure can be entirely legitimate. It becomes a security issue only if the operation writes outside the intended region, exposes protected information or otherwise crosses the expected boundary.

The research has widened the picture of the accessible syscall surface, but it has not found a confirmed Sony-specific kernel vulnerability that completes the exploit chain.

The value of failed experiments

One reason the 14.10 project is worth following is that its documentation does not stop at the first promising interpretation.

The ROP-chain theory was revised after the syscall wrapper kept working with the suspected execution structure corrupted. The function-pointer redirection was dropped when the pointer proved irrelevant to the real call path. Several kernel information-leak theories were abandoned after the tested interfaces returned sanitised data or nothing useful, and the AIO route was narrowed when the alternate syscall path produced the same process termination.

Security research is prone to false positives. One unexpected return value can look like a leak, a successful write can look like control over a function pointer, and a syscall that accepts a request can be mistaken for one that grants privileged access. A rigorous investigation asks what else could explain the observation and designs a test that tells the explanations apart.

In the ROP case the question was whether the syscall dispatcher used the modified pointer. The researchers changed the pointer and chain and watched whether behaviour changed. It did not, so the original model no longer fit. In the KASLR work the question was whether a returned value was a real kernel address. The surrounding structures showed that the candidates were sanitised or sentinel values, which removed several proposed leak paths. In networking, a packet reaching a kernel parser is a useful observation, but successful delivery is not memory corruption, and a malformed packet rejected without a crash is evidence about the tested input and nothing more.

This is less exciting than a claim of an imminent jailbreak, but it is what makes the work useful to other developers and security researchers.

What would a genuine firmware 14.10 jailbreak require?

Several milestones sit between the existing userland environment and a working jailbreak.

First, the project needs a new vulnerability or primitive that crosses the boundary it has not yet crossed. That could be a previously untested kernel interface, a genuine information leak or a memory-safety flaw in a reachable code path, demonstrated and not inferred from an ambiguous return value.

Second, the research has to establish how the primitive affects the kernel. A pointer leak might help defeat KASLR, and a memory corruption bug might lead to kernel read/write access. Those are different capabilities and each needs its own validation.

Third, any resulting exploit has to be reliable under the target firmware’s restrictions. One that depends on an address staying fixed across process launches, or on a syscall that is consistently blocked, will not form a dependable chain until those conditions are dealt with.

Finally, the researcher would need to find out which protections remain after kernel access. A kernel exploit does not automatically give unrestricted control over every hardware-backed security mechanism, and the privileges obtained and the boundaries still enforced would decide what comes next.

The repository’s own roadmap reflects this. Its stated objective runs from userland execution to kernel read/write access and then to a hypervisor bypass, as separate stages and not one completed exploit. ¹ The available evidence does not show the project crossing the kernel boundary. Researchers have built a way to study the environment and are still looking for the missing primitive.

Why hardware and firmware research must remain separate

The wider PS5 security picture includes both software vulnerabilities and hardware findings. It is tempting to treat every new disclosure as proof that the console’s whole security model has collapsed, but the technical consequences depend on which component is affected.

The BootROM discussion in The CyberSec Guru’s report on PS5 ROM keys concerns reported material tied to the console’s hardware root of trust. A BootROM runs at the earliest stage of startup and helps establish the chain of trust used to verify later boot components. A disclosure at that layer has different implications from a kernel bug, depending on which keys are authentic, what they protect and how the platform uses them.

Firmware updates generally cannot rewrite immutable code physically embedded in a processor. That does not make every consequence of a BootROM-key disclosure exploitable, and it does not make later security layers irrelevant. The practical impact depends on the cryptographic roles of the disclosed secrets and the protections that remain.

The Store redirect report concerns another layer. As the PlayStation Store redirect coverage explains, the Store application delivered custom web content in a demonstration on firmware 11.40. The Store itself was not the underlying vulnerability. The entry point depended on reaching a web host and executing a compatible exploit chain.

Neither report establishes a firmware 14.10 kernel exploit. The Store demonstration involved a different firmware and a WebKit-related entry mechanism, and the ROM-key report concerns the boot trust chain. The 14.10 research is about access from a restricted game process to the operating system’s kernel. Console exploitation is best understood as a sequence of security boundaries, and a discovery in one layer can open new research without defeating the others.

The remaining challenge: turning observations into a reliable primitive

The biggest open question is whether the interfaces reachable from the current research environment contain a vulnerability that can give kernel memory access.

The repository has already ruled out a number of straightforward ideas. The tested physical-memory interface did not expose the CPU memory region the researchers wanted. The proposed ROP chain was not used by the syscall dispatcher, and the suspected loader function pointer was not a working control-flow target. The tested AIO operations stayed blocked, and several proposed kernel address leaks returned sanitised values or nothing useful.

That is not a dead end, but the next useful discovery will have to differ from the routes that have already failed. It will need to answer a concrete technical question. Does a particular interface expose a genuine kernel pointer? Does a specific input corrupt a kernel object? Does an operation violate an invariant that should hold for an unprivileged process? And can the effect be reproduced and told apart from a normal error or an artefact of the test harness?

The public records also let other researchers check the assumptions independently, which is valuable in a field where many claims circulate before the code or evidence is available. A reproducible finding can be examined, challenged and improved. A vague claim that a console is “hacked” gives far less to work with.

For anyone following the project, the better signal is a change in its documented capabilities, not new probe filenames or bigger test counts. The decisive milestones would be a verified kernel address leak, a demonstrated kernel memory corruption primitive or a reproducible transition to kernel read/write access. Until one of those is published and independently substantiated, the project remains an investigation into the remaining attack surface and not a confirmed jailbreak.

The bottom line: PS5 firmware 14.10 is under investigation, not confirmed jailbroken

The 14.10 campaign gives a detailed look at what it takes to investigate a hardened console from inside a restricted process. Its Lua loader supplies a repeatable environment, its syscall experiments separate userland filtering from kernel enforcement, and its memory and networking probes show which interfaces are available.

The research has also corrected several early assumptions. The proposed ROP chain did not control syscall execution, the suspected function-pointer redirection did not produce native code execution, the tested AIO calls stayed blocked, and the investigated kernel information-leak paths did not yield a reliable KASLR bypass. Those findings substantially narrow the techniques that can currently be considered viable.

The BootROM-key disclosure raises questions about hardware trust and cryptographic material, and the Store redirect demonstration shows how an application can serve as an entry point for a compatible WebKit exploit. Neither is proof that firmware 14.10 has been jailbroken.

The researchers have a working userland environment, a map of much of its accessible interfaces and a list of dead ends. What they still lack is a demonstrated way to get kernel memory access and turn it into a reliable exploit chain. Until the repository documents that, claims that firmware 14.10 has been fully hacked go beyond the available evidence.

Primary research source: ZigZagBoi1/PS5-14.10-Research on GitHub

Related coverage from The CyberSec Guru:

• PS5 ROM Keys Leaked: Sony’s Unpatchable Security Nightmare
• PS5 Jailbreak: PlayStation Store Can Be Redirected to a Custom URL to Launch a WebKit Jailbreak