Burp Browser Not Available on Kali ARM64: 7 Checks

Confirm the launcher before changing the browser

PortSwigger states that its embedded browser is unavailable in JAR-launched instances on ARM64 and Apple Silicon; the native platform installer is the documented route. Record OS architecture, installer type and the actual launch error. A dedicated external browser can be another workflow, but its listener, proxy and CA trust must be checked independently. Do not use a disabled sandbox or ignored certificate warning as a routine repair. Source and scope.

Burp Browser Not Available on Kali ARM64? Check how Burp was installed before changing Java, proxy ports, or UTM networking. PortSwigger currently supports Linux ARM64 through its native installer. Its embedded browser is not supported when Burp is launched from a JAR on ARM64. In that case, use the native Linux ARM64 installer or connect an external Firefox browser to Burp.

That distinction comes from PortSwigger’s system requirements, checked on October 9, 2026. The steps below are documentation-based guidance, not a claim that every Kali/UTM combination has been tested.

Start with the symptom you actually see

What happens	Start here
Burp opens, but Open browser fails	Checks 1–3: installation and browser launch.
Firefox cannot reach Burp’s local page	Checks 4–5: listener, proxy address, and exceptions.
HTTP appears in history; HTTPS shows a trust warning	Check 6: the CA in the correct Firefox profile.
A page keeps waiting	Check Intercept first; a held request can pause loading.

Scope: These instructions assume Burp and Firefox run inside the same Kali ARM64 VM on UTM. Use only your own applications or explicitly authorized labs. Keep personal browsing and accounts out of the testing profile. If you are still assembling a lab, the essential Kali tools guide explains where a web proxy fits in the workflow.

1. Identify the Kali architecture and Burp launcher

Run these read-only checks in Kali, then record Burp’s version from its About dialog and whether you started it from an installed application, the Kali menu, or a java -jar command:

uname -m
dpkg --print-architecture
command -v burpsuite

An ARM64 guest normally reports aarch64 and arm64 in the first two outputs. The third command locates a launcher on your PATH; it does not prove how that launcher starts Burp. A missing result also does not mean a separately installed Burp application is absent. Record your actual launch method instead of assuming the menu entry uses the installer you downloaded.

The guest operating system determines which installer you need. A Kali VM on an Apple Silicon Mac needs a Linux build; a macOS installer is for Burp running directly on the Mac. Keep those two environments separate in your notes.

2. Use the native Linux ARM64 installer for the built-in browser

For the embedded browser on an ARM64 guest, follow PortSwigger’s download and installation guide and select the native Linux ARM64 package for your edition. Preserve your existing projects and settings before changing installations. Launch that specific installed application so an older menu shortcut does not silently reopen another build.

Then choose Proxy → Intercept → Open browser. If it opens, continue with an authorized test page. Burp’s built-in browser is already configured for its proxy; the external Firefox setup below is a separate route.

If you intentionally keep a JAR-based ARM64 setup, skip to check 4. Replacing Java alone does not remove the documented embedded-browser limitation. Burp’s proxy and an external browser can still be used without making the embedded browser launch.

3. Check the desktop and browser launch error

If the native build still fails, record the exact error and whether you have a working graphical Kali desktop. Start Burp as your normal desktop user. Do not add sudo or disable the browser sandbox as a routine fix.

PortSwigger’s browser settings documentation describes sandbox restrictions in some Linux root contexts and warns that running without a sandbox increases risk. It also documents possible crashes when GPU access is enabled but no usable GPU exists. Treat either as a specific diagnostic lead only when your error supports it.

Capture the launch error or terminal output before changing a dependency, display setting, or browser option. Change one item, repeat the same check, and keep the result. Avoid deleting configuration directories or reinstalling a whole desktop without evidence. If Firefox works through Burp, you can continue the lab while investigating the embedded browser separately.

4. Confirm the local proxy listener

Open Settings → Tools → Proxy → Proxy listeners. For the same-VM setup, confirm a running listener on 127.0.0.1:8080. If your configured port differs, use that same port in Firefox. A listener that cannot start needs its error investigated; a port conflict is one possible cause.

For the first connectivity check, set Proxy → Intercept to Intercept is off. This lets requests continue while you inspect history. Otherwise, a request waiting for your decision can look like a broken network. See PortSwigger’s proxy troubleshooting guide.

Keep the browser and listener in the same VM

127.0.0.1 means the machine where the browser is running. In Firefox on macOS, it points at the Mac, not the Kali VM. The simplest setup here is to open Firefox inside Kali. Do not widen the listener to every network interface just to compensate for a host/guest mix-up. UTM’s external network mode does not change this loopback address.

5. Configure Firefox and prove the proxy path

Use a dedicated lab Firefox profile inside Kali. In Settings, search for proxy and open the connection/proxy configuration dialog. Menu placement varies by Firefox version; Mozilla’s connection settings guide shows the current locations.

1. Select Manual proxy configuration.
2. Set HTTP Proxy to 127.0.0.1 and Port to 8080, matching the listener.
3. Enable Also use this proxy for HTTPS.
4. Inspect No Proxy For: the lab hostname you want to capture must not be excluded. Also check whether an extension controls these settings.
5. Save, then visit http://burpsuite in this same profile. Burp’s local page should load through the proxy.

Next, request a harmless HTTP page on your authorized lab target and find its host and path in Proxy → HTTP history. If history appears empty, inspect its display filters before concluding no traffic arrived. Do not use a login, payment, or personal account page as your connectivity test. PortSwigger also provides a Firefox setup walkthrough.

Stop point: If neither the local Burp page nor the lab request works, return to the listener and Firefox settings. Importing certificates cannot repair an unreachable proxy. If Burp receives the request but the target fails, record the response and event-log error; target reachability is a different question.

6. Import Burp’s CA into your lab Firefox profile

After the proxy path works, follow PortSwigger’s Firefox CA procedure:

1. At http://burpsuite, download CA Certificate from your own running Burp instance.
2. In the same lab Firefox profile, open Settings → Privacy & Security → Certificates → View Certificates → Authorities.
3. Import the downloaded certificate and enable its website-identification trust option. Labels can vary by version.
4. Restart Firefox, request an authorized HTTPS lab page, and confirm it loads without a certificate warning and appears in HTTP history.

If a warning remains, record its exact code and check that the imported CA belongs to the current Burp instance and the active profile. Replacing a Burp installation or CA can leave an old certificate behind. Do not click through warnings or disable certificate validation as a substitute for fixing trust.

Keep this CA in the testing profile. When retiring that profile or interception setup, restore its prior proxy settings and remove Burp’s CA from Authorities, then restart Firefox. Do not install an unknown CA downloaded from a forum or shared troubleshooting bundle.

7. Verify the result and record useful evidence

Use the following pass/fail record instead of “it seems fixed.” These are checks for you to perform, not results claimed by this article.

Check	Evidence to record
Embedded browser, if you chose that route	Native Linux ARM64 build, Burp version, and whether Open browser launches.
Proxy connectivity	Running listener address and port; the expected lab host/path in HTTP history.
HTTPS trust	Expected HTTPS request in history and no certificate warning.
Interception control	On one harmless lab request, Intercept pauses it; forwarding releases it. Return Intercept to off afterward.

If you need help, copy this small record and remove cookies, authorization headers, credentials, personal details, and private target identifiers before sharing it:

Kali architecture:
Burp version + install/launch method:
Burp location / Firefox location:
Listener address + port:
http://burpsuite loads: yes / no
Lab HTTP request appears in history: yes / no
Lab HTTPS request loads without warning: yes / no
Exact error + one change tried:

For a reproducible failure on a supported native build, this record gives support a useful starting point. It also prevents you from repeating a change that already failed. A successful proxy check does not establish that the application itself is secure.

FAQ: Burp Browser Not Available on Kali ARM64

Is Linux ARM64 unsupported by Burp?

No. Current requirements list native Linux ARM64 support. The relevant restriction is the embedded browser when Burp is run from a JAR on ARM64. Check the current requirements again when upgrading.

Does a Kali package automatically mean the browser will fail?

Do not infer that from the package name alone. Record the actual version and launcher. For the documented native ARM64 route, use PortSwigger’s installer for the guest platform.

Should I change Java, DNS, or UTM networking first?

Start with the failed layer. A browser launch error, an unreachable listener, a target DNS failure, and a certificate warning need different evidence. Avoid changing all four at once; it destroys the comparison you need to identify a fix.

Can I just use external Firefox?

Yes, for the proxy workflow described here. Configure its proxy and CA explicitly. This is an alternative workflow, not a guarantee that Firefox is safer or faster than the built-in browser. Choose the browser your authorized test requires.

Choose your next lab task

Once HTTP and HTTPS checks pass, stop changing the environment and return to the application you intended to test. If it uses WebSockets, continue with the Burp WebSocket workflow to find the upgrade handshake and inspect messages in the appropriate history view.

Documentation reviewed: October 9, 2026. Official references are linked beside the relevant steps. Interface labels and supported platforms can change; use the linked vendor instructions for your installed release.