> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/changelog.md).

# Release and migration notes

What changes in Pro 4.0.0 and Server 1.0.0, and how to upgrade your existing setup.

This guide covers **Burp Bounty Pro 4.0.0** and the first commercial **Burp Bounty Server 1.0.0** release. Documentation updated on **14 October 2026**.

| Component          | Version and where to check it                                                       |
| ------------------ | ----------------------------------------------------------------------------------- |
| Burp Bounty Pro    | **4.0.0**, shown in About.                                                          |
| Burp Bounty Server | **1.0.0**, shown in the startup banner and MCP `server_info.version`.               |
| Server scan engine | Reported separately as `server_info.engine_version`.                                |
| Profile pack       | Versioned independently; use the version supplied with your pack or profile update. |

## Burp Bounty Pro 4.0.0

### Keep your setup across updates

Pro stores its settings independently of the JAR name and location. The profile directory, license key and activation cache, Burp Bounty Servers, AI provider/API key/model/endpoint, custom prompts, variables, proxy settings and live scanner preferences survive replacing the JAR when their saved storage is retained. Existing Burp preferences and known legacy activation files are migrated. A valid adjacent `BurpBountyData` pack is detected on a new installation.

Use **Settings → Storage** or the documented startup override when the default user directory is not writable. See [installation, migration and permissions](/burp-bounty-pro/installation.md).

The six legacy redirect and file variables are restored once during migration, preserving existing values. Later edits and deletions stay saved. See [variable defaults](/creating-profiles/global-variables.md#pack-defaults).

### Scan controls and results

* Right-click choices are **Local Scanner** and **Burp Bounty Server Scanner**. Configure remote endpoints in **Settings → Burp Bounty Servers**.
* Manual Local Active and Server Scanner dialogs default to **Concurrency 5** and **10 requests per second**. Other workflows retain their own controls and defaults.
* Server Scanner defaults to **Show one success payload for insertion point**. Choose the all-payload option when you want to continue after successful matches.
* Local scans that complete some requests before an error or interruption display **Finished** in green, retaining their actual counts and findings. **Failed** remains for errors before any requests complete; **Cancelled** remains for cancellations. Finished does not guarantee complete coverage.
* **Clear** removes the Active table's current rows and evidence views. Late updates cannot restore those cleared rows. It does not cancel running work or remove findings from Burp; **Remove Selected** requests cancellation and removes the selected rows.
* Remote passive findings appear both in Burp's issues and **Scanners → Passive**. Terminal remote entries include end times. Controls and reconnection use the server that owns each scan ID.

See [scan controls and performance](/burp-bounty-pro/scan-control.md) for the full state table, budgets and cancellation behavior.

### Local performance and compatibility

Local scanning prepares payload work on demand, bounds internal worker pools, groups progress refreshes and reuses compiled regular expressions and response search data. These changes reduce planning overhead and thread accumulation; Burp and its extensions still share the same JVM resources. See [resource protections](/burp-bounty-pro/scan-control.md#reducing-laptop-load).

The extension Output tab includes a local timing summary with HTTP time, budget/pause waits, elapsed time, response outcomes and slow-call counts. The performance guide explains how to compare it with target-side measurements, including HTTP/1 connection handling and HTTP/2 request concurrency.

Use the complete release JAR for the Apple Silicon JNA licensing fix. Existing profile editing, multi-step scans, Smart Scan and AI Scanner remain available; these capabilities are not all new to version 4.0.0.

## Burp Bounty Server 1.0.0

REST remains available when MCP is enabled. The Streamable HTTP `/mcp` interface supports catalogue discovery, explicit HTTP services, supplied passive exchanges, validated profile selection, lifecycle controls, compact status, paginated findings and individual evidence retrieval.

Register multiple servers in Pro, as separate MCP connections in an agent, or both. Pro distributes batches; agents can explicitly divide work across their connections. Each server retains its own scan IDs, limits and history. See [multiple servers](/burp-bounty-server/distributed-scanning.md).

Persistent findings have bounded retention and storage, with explicit differences between MCP and REST defaults. Pending approvals expire and are bounded. MCP destination checks use the service origin. The approval routes intentionally share the license credential and do not provide separate operator authorization.

`$BBOUNTY$` selects one exclusive request span for Server active scanning; it is not a Local Scanner switch. Startup validates an explicitly supplied catalogue directory. Debug controls routine diagnostics; shutdown handles MCP connections.

Server revalidates licenses every 15 minutes, enforces a bounded 24-hour grace period for temporary validation outages and preserves access to results when scanning is blocked. A confirmed license rejection cancels current scans and blocks new work.

Update the executable with `--update` and the official catalogue with `--update-profiles --profiles-dir ...`. Run these commands separately after stopping the affected service, then restart it explicitly. Startup does not install updates automatically. See [Server updates and rollback](/burp-bounty-server/installation.md#stop-and-update).

## Licensing and deployment

Licenses are **per individual user**, for both monthly and annual plans. Pro includes Server access and shares **10 registered activations in total** across the two products. A standalone Server license permits **10 Server activations** and does not activate Pro. Additional users require their own licenses. See [users, products and activations](/licensing.md).

## Upgrade an existing installation

1. **Keep a rollback copy.** Retain the previous JAR/executable and back up your data pack and user configuration before replacing files. Protect backups containing license keys or AI credentials.
2. **Replace Pro's JAR and retain its storage.** Unload the old extension, load the intended 4.0.0 JAR and check its full path in Burp. Verify the restored license, profile directory, server entries and AI settings. Do not keep duplicate versions loaded.
3. **Check the data pack path.** The pack is now named `BurpBountyData`. Pro recognizes a saved `BurpBountyData_3.0` directory renamed in the same parent directory. For other moves, select the new location in Settings. Server's `--profiles-dir` must point directly to the `profiles` subdirectory.
4. **Replace older Server builds manually for the first migration.** The development 2.0.0 updater does not select the new 1.0.0 release channels. Stop it, install the commercial binary for your platform and start it with your existing configuration. Use `BURPBOUNTY_LICENSE_KEY` in the process environment and `X-BURPBOUNTY-LICENSE` in clients. Subsequent 1.x releases use the new updater.
5. **Verify a small scan before a larger batch.** Check the selected profiles, service protocol/port, rate limits, findings and available warnings. Missing Collaborator support can leave callback-dependent checks unexecuted even when the displayed state is Finished.

## Profile and rule corrections

* Local multi-step payload preparation applies variables, selected URL encoding, append/insert positions, encoder chains and payload replacement rules. Path discovery encodes literal spaces without double-encoding existing escapes.
* Smart Scan requires all And conditions in the same exchange, reserves First Match actions atomically per origin and deduplicates overlapping actions within a rule.
* The WordPress rule uses the exact installed `Easy_wp_smtp_listing_enabled` profile name.
* Server honors `.bb` Never redirects, relative locations and hop limits, supports isolated step cookie reuse, and explicitly rejects active Burp-scope/variation settings it cannot execute.
* Pro cookie reuse handles replacement/deletion and attributes; redirect URL resolution preserves explicit ports and rejects misleading hostname suffixes. Remaining redirect-method and multi-step differences are documented in [engine compatibility](/creating-profiles/compatibility.md).

## Profile creation and reference guides

Profile creation is documented through Pro's graphical editor: named controls, steps, saving with OK and distributing the generated `.bb` file. JSON fields and IDs are retained as an exported-file reference for integrations.

MatchType values, insertion IDs, typed grep columns, time units, showIssue behavior and rule serialization now follow the source. Compatibility notes document remaining engine differences. The reviewed pack inventory separates total profiles from enabled profiles and records missing rule dependencies.