Authentication bypass in PortSwigger Burp Suite DAST

In PortSwigger Burp Suite DAST (formerly Burp Suite Enterprise Edition) before 2026.8, an authentication bypass can occur via an alternate path or channel.

• PortSwigger Burp Suite DAST: version 2021.11 and versions less than 2026.8 are marked affected.
• The record sets default_status to unaffected outside the listed affected version entry.
• PortSwigger identifies release 2026.8 as containing the security fix.
• The available evidence does not enumerate additional release branches or deployment variants.

The weakness is classified as CWE-288, Authentication Bypass Using an Alternate Path or Channel. The vulnerable behavior is an authentication decision that can be bypassed through an alternate path or channel. The supplied assessment characterizes the flaw as network-reachable, low complexity, requiring no prior privileges and no user interaction. An additional attack requirement is present, but the record does not identify what that requirement is. Details about attacker-controlled input, endpoints, requests, or the specific authentication logic are not disclosed. An exposed DAST service endpoint or management path is therefore a possible reachability concern, but that is an inference rather than a confirmed deployment detail.

• The flaw is reachable over the network.
• The supplied assessment states that exploitation requires no prior privileges or user interaction and has low complexity.
• An additional attack requirement is present, but its exact nature is not public.
• The supplied record does not mark the vulnerability as known exploited and sets public_exploit to false; the CISA enrichment included in the GCVE record reports exploitation as none. This is a status assessment, not proof that exploitation is impossible.

The flaw can allow authentication to be bypassed and protected Burp Suite DAST functionality to be accessed without authorization. The recorded impact to confidentiality, integrity, and availability within the vulnerable component is high, so a successful attack could potentially expose or alter data and configuration or disrupt service, depending on the functionality reached. Impact outside the vulnerable component is assessed as lower. The post-bypass permission level, tenant boundary, and any possibility of code execution are not identified in the public record.

A successful bypass could give an attacker access to DAST functionality that normally requires authentication and reduce trust in the organization's security-scanning service. Based on the recorded impact, data or configuration in the affected component could potentially be read or changed, and the service could potentially be disrupted; these are possible consequences, not a confirmed incident. Loss of control over scan results or configuration could delay vulnerability handling and remediation decisions. The record does not identify a breach, data disclosure, campaign, victim, or specific business incident.

1. Upgrade PortSwigger Burp Suite DAST to 2026.8, which the vendor release notes identify as containing the fix.
2. Separately inventory deployments still identified as Burp Suite Enterprise Edition and include them in the upgrade plan if they are affected Burp Suite DAST deployments.
3. If an immediate upgrade is not possible, restrict network access to affected instances to trusted administration or scanning networks. This is a temporary exposure-reduction measure, not a vendor-confirmed fix.
4. After the upgrade, verify that each instance is running 2026.8 and remove or isolate any remaining older deployment.
5. The record does not provide another vendor-specific interim mitigation.

1. Inventory all PortSwigger Burp Suite DAST deployments, including systems previously identified as Burp Suite Enterprise Edition, and compare their versions with the affected range.
2. Identify instances with service endpoints or management paths reachable from untrusted networks. This is a precautionary exposure check, not a confirmed exploitation indicator.
3. Review access and authentication logs for successful access that lacks the expected authentication context or shows unusual source behavior. The vendor has not published a specific event, log pattern, or IOC for this vulnerability.
4. After updating, recheck the inventory to confirm that every instance is running a release containing the fix and that no older deployment remains.
5. Do not treat the absence of suspicious log entries as proof that a system is safe.