ps5-webkit-autoloader: moving the exploit server from someone else's machine to your own

The problem is a dependency on a stranger's DNS server

The README explains the design in a way that is worth reading in full, because the problem is not the exploit.

WebKit exploits are usually loaded by pointing your PS5's DNS at some server hosted by someone on the internet. That means you are putting your trust in whoever runs that server, and if it goes down, changes, or disappears, your setup breaks.

That is a real engineering objection, not a political one. A jailbroken console whose boot path depends on an unaffiliated web host has an availability problem and a trust problem, and both get worse over time as the host's interest fades.

The alternative this project takes is fully offline with no third party DNS. After a one time install from your PC, everything is served straight from the PS5, so there is nothing external to go down or change behind your back. The second property is one time setup followed by a homescreen shortcut, so once it is installed you need neither a PC nor the internet, just launch WebKit Autoloader from the homescreen.

The third property is that payloads are loaded the way the ecosystem already works. After the exploit chain runs, payloads are sent the same way they are in the Y2JB, BD-JB and Lua autoloaders, via Payload Manager or a custom autoload.txt.

So the contribution is not a new exploit. It is a change of who serves the page, and a caching scheme that lets the console serve it to itself afterwards.

Two setup paths, split by whether you are already jailbroken

The setup instructions branch on one question, and the branch is the whole design.

If you are already jailbroken, the path is short. Download webkit-autoloader-installer_vX.Y.Z.elf from the Releases page, send it to the PS5 with elfldr or launch it from Payload Manager, and the installer opens the browser to cache the autoloader page, choosing Poops or Relapse if prompted, creates the WebKit Autoloader app on the homescreen, and exits. You then reboot once and launch WebKit Autoloader from the homescreen.

If you are not jailbroken yet, you need to host the exploit locally on your PC for the initial setup. Download webkit-autoloader-host.py, or the .exe version, from Releases and run it on a PC on your network. On the PS5, set your network's DNS server to your PC's IP address. Open the User's Guide from Settings to run the installer, which adds the WebKit Autoloader app to the homescreen. Then reboot once and launch it from the homescreen.

Note what the second path requires: the console's DNS has to point at your machine, which means you are operating a local web server that the console will trust during setup. That is the same trust that the project is trying to move away from, except that in this case you are the operator and you can turn the server off when the install is done.

The reboot is mentioned in both paths and is not incidental. The homescreen app has to be registered with the system before the console will offer it, and the README also states that the autoloader content is cached on the console, so updating is exactly the same as the initial install, following the setup instructions again with the new release files.

Payload Manager when nothing is configured, autoload.txt when it is

There are two ways to configure payloads, and the choice is automatic rather than a preference.

If no autoload.txt config is found, the autoloader automatically launches Payload Manager, a PS5 payload manager with a web UI. That lets you configure and send payloads directly from your browser, without manually setting up config files or transferring ELF files ahead of time. The instruction is simply to run the autoloader, and if there is nothing configured, Payload Manager starts.

The documentation also notes that Payload Manager has its own built in autoload feature, which lets you configure payloads to load automatically on startup, all managed through its web UI. The project is explicit that this is separate from the autoload.txt mechanism.

The manual path is for a fixed, automated payload chain. You create a directory named ps5_autoloader, place your .elf and .bin files inside it, and add an autoload.txt file listing the files you want to load, one filename per line. Filenames are case sensitive, and the loader waits when you add a line like !1000, which makes it wait 1000 ms before sending the next payload.

The directory goes in one of two locations, in priority order, the root of a USB drive first and the internal drive at /data/ps5_autoloader second.

One interaction is worth flagging because it is easy to trip over. When an autoload.txt config is found, Payload Manager is not launched automatically. If you want both, you place pldmgr.elf in the ps5_autoloader directory and add it to autoload.txt yourself.

The bundled elfldr only answers the console itself

This is the security design of the project and it is stated in one paragraph.

The autoloader uses a custom version of elfldr that only accepts connections from the PS5 itself, that is, from localhost. The stated reason is that this improves security by preventing unauthorized devices on your network from sending payloads to your console.

That is a meaningful boundary. A conventional ELF loader will accept a payload from any device that can reach it, which on a home network means anything running on that network. Since the whole point of the autoloader is that the console serves the page to itself over the local network, restricting the payload channel to localhost closes the obvious gap that would otherwise exist.

If you want a normal ELF loader that allows sending payloads from any device, the documentation says you can load it through Payload Manager instead. And if you are using a manual config file, you can place your custom loader such as elfldr.elf in the ps5_autoloader directory and add it to autoload.txt.

There is a wrinkle in that case, and the documentation explains why. If you are loading other payloads right after elfldr.elf in your autoload.txt, you need to add a sleep command immediately after it, like !4000, to give the new ELF Loader time to start up and listen before subsequent payloads are sent. The example in the README shows the whole pattern.

# Load custom ELF Loader
elfldr.elf
# Give it 4 seconds to start up (only needed if sending more payloads)
!4000
# Send other payloads
etaHEN.elf

That sleep is a race condition handled by hand, and it is the price of swapping in a loader that can be reached from elsewhere.

A native installer built with a PS5 toolchain and a Python builder

The repository is a hybrid, and the Makefile shows how the pieces fit.

The installer is C. The Makefile points CC at the prospero-clang in a PS5 payload SDK at /opt/ps5-payload-sdk, sets STRIP to prospero-strip, and compiles src/main.c and src/http_server.c together with common sources pulled from the third_party remote loader checkout, linking against a static libmicrohttpd and the SceNetCtl, SceUserService, SceSystemService and SceAppInstUtil libraries. The flags are -Os with function and data sections, and the linker garbage collects sections. The HTTP server is in there because the installer has to serve something to the browser during the caching step.

The page side is built by Python. The builder is run through the remote loader's own build_standalone.py, and the chains are poops and relapse, one standalone page per chain carrying elfldr-check.js, the chain's exploit, and then autoload.js. The chain sources come from unmodified submodule payloads, and each exploit prefetches elfldr and kexp itself. The appearance of the autoloader page is injected through the upstream builder's hooks, with the CSS and JS paths passed in as variables.

The version and title come from tools/gen_version.py, and the Makefile notes that one version is produced per make invocation, including for dirty tree builds, which is the kind of detail that matters for reproducible artefacts.

The developer workflow is documented too. Build both release artifacts with ./build_release.sh, which requires Docker, and the build uses the remote loader's standalone HTML and host builders directly. Run make test for the offline checks covering the payload, installer and exploit selection flow, and make dev for a local page preview. The architecture and cache layout are described in ARCHITECTURE.md.

Where the offline promise stops, and what the project does not tell you

Two limits are worth naming.

The first is firmware coverage. The README states support for firmwares 7.00 to 13.60, and the exploit selection is per chain, with the Makefile building a page for poops and a page for relapse. A console outside that range has no covered chain, and the installer is where you would find out, because choosing Poops or Relapse is part of the install step.

The second is the payload side. The loader sends whatever ELF or BIN files you configure. The autoloader itself is a delivery mechanism, and the documentation does not constrain what the payloads do, because it has no reason to. That is worth understanding plainly: this project solves a serving and caching problem, and the payload content is a separate decision that the project deliberately leaves to the user.

What the documentation does not cover is also worth naming, so nobody goes looking. There is no statement about how the cached page is stored on the console, beyond the update note that the content is cached and that updating is the same as the initial install, and ARCHITECTURE.md is where the build and cache layout is described. There is no rollback procedure, and no statement about what happens if a cached page is corrupted. There is no guidance on the legal side, and the reader who is considering this on a retail console is left to work out the terms of the platform themselves.

The last point is the one that most affects who should install this. The console is a retail device, the firmware is signed, and running unsigned code on it is something the platform's terms of service address. This project is a technical tool for hardware you own, and reading it as anything other than that is a mistake.

Editorial conclusion

ps5-webkit-autoloader fits a console owner who has already exploited or jailbroken their own PS5 and wants the loader to stop depending on a third party web server, and it fits developers who want to test their own WebKit payloads against a local page rather than a hosted one. It does not fit someone whose firmware falls outside the supported range, and it does not fit anyone looking for a supported or sanctioned way to run unsigned code on a retail console. Check three things before you rely on it. Check your firmware against the supported range, 7.00 to 13.60, because the exploit selection is per chain and a console outside the range is not covered. Check how you will get the payload onto the console, since the two setup paths differ, one using elfldr or Payload Manager on an already jailbroken console and one requiring a local host with the console's DNS pointed at your PC. And check the loader trust boundary, because the bundled elfldr only accepts localhost connections, which is the security property that makes the offline design worthwhile. The last push was on 2026-10-08, the newest release is v0.6.1 from the same day, and the license is GPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. itsPLK/ps5-webkit-autoloader on GitHub
3. License: GPL-3.0
4. README
5. Releases