Loading story…
Internet-facing Perforce Helix Core servers are widely exposing sensitive data because insecure default settings leave source code and administrative functions accessible without proper authentication. Research by Morgan Robertson found that 72% of 6,122 publicly reachable P4 servers allowed unauthenticated read-only access through a default-enabled remote user account, while 21% had at least one account with no password and 4% exposed an unsecured superuser account capable of full system compromise. Among 2,826 servers still active at their original IP addresses, 54% continued to permit unauthenticated read-only source code access, affecting organizations including software, automotive, industrial, and banking-sector firms.
Supporting research tools published on GitHub describe multiple weaknesses in exposed deployments, including unauthenticated user enumeration, server information disclosure, passwordless accounts, accessible remote depots, and weak authentication rate limiting over the Perforce protocol on port 1666. The project says servers running versions below 2025.1 with security levels below 4 are vulnerable to remote depot exposure, while security levels below 3 weaken login protections. Robertson said Perforce and more than 60 impacted entities had been notified, and recommended hardening measures such as enabling run.users.authorize=1, setting dm.info.hide=1, assigning passwords to all accounts, and raising security levels to 3 or 4 as appropriate.
Map this exposure pattern across your cloud, code, and identities.
6 events from the most recent confirmed update back to the earliest known activity.
A notice for CVE-2026-6043 said P4 Server versions before 2026.1 use insecure default settings that can enable unauthenticated user creation, user enumeration, passwordless account access, and depot access via the built-in remote user. It said the upcoming P4 Server 2026.1 release, expected in May 2026, will enforce secure-by-default configurations for upgrades and new installations.
Public CVE writeups described the full multi-step exploit chain behind CVE-2026-33318, including missing authorization on POST /account/change-password, unconditional password-hash updates, an anonymous admin account created during migration, and login logic that trusted a client-supplied loginMethod. The disclosures clarified that privilege escalation depended on the combined chain rather than any single flaw alone.
Actual addressed a privilege-escalation flaw affecting servers migrated from password authentication to OpenID Connect in version 26.4.0. The issue required chaining weaknesses in password change handling, retained inactive credentials, and login-method trust to let a BASIC user become ADMIN.
SC Media reported Robertson's findings that 72% of 6,122 online Perforce P4 instances allowed unauthenticated read-only source-code access, 21% had at least one passwordless account, and 4% exposed an unsecured superuser account. The report also said Robertson had notified Perforce and more than 60 impacted organizations.
A GitHub repository for the P4WNED project was published with scanning tools, Nuclei templates, and Metasploit modules for assessing Perforce weaknesses such as remote depot exposure, user enumeration, and weak rate limiting. The repository stated that some issues affected versions below 2025.1 depending on security settings.
Morgan Robertson published P4WNED research describing widespread insecure default configurations in internet-facing Perforce Helix Core servers, including unauthenticated source-code access, passwordless accounts, and weak authentication controls. The research also included tooling and remediation guidance for affected deployments.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
6 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcecvefeed.io
Open sourcecvereports.com
Open sourcescworld.com
Open sourcegithub.com
Open sourcemorganrobertson.net
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
OWASP's **API Security Top 10** identifies broken object-level and function-level authorization, excessive data exposure, security misconfiguration, and unsafe trust boundaries as leading API risks, warning that business logic abuse and operational gaps often turn ordinary endpoints into high-impact exposures. Those patterns were reflected in newly disclosed incidents involving both enterprise software and consumer-facing platforms, where low-privileged access was enough to reach data and functions intended for administrators or other users. In **CVE-2026-46515**, Frogman versions before `1.6.3` allowed users with only `PERM_READ` privileges to access administrative PBX data through MCP and HTTP APIs, including AMI manager secrets, outbound dial PINs, SIP secrets, backup paths, CDR history, and even root SSH connection commands; the flaw also enabled arbitrary execution of saved GraphQL queries and was rated **CVSS 9.3**. Separately, a bug bounty report on Target's Academy platform showed how two seemingly low-risk APIs could be chained to enumerate users and expose PII at scale, underscoring how weak authorization controls across interconnected endpoints can escalate routine API functionality into serious data disclosure.
Jul 19, 2026
Internet-exposed Model Context Protocol (MCP) servers are frequently running without authentication, allowing anonymous users to enumerate available tools, retrieve sensitive enterprise data, and in some cases access destructive backend actions, credentials, or code-execution capabilities. Wiz found MCP deployments in 80% of surveyed cloud environments; roughly one in six environments had at least one publicly exposed server, 70% of those servers disclosed tool inventories anonymously, and 42% returned real data to unauthenticated tool calls. Many affected deployments use the pre-authentication `2024-11-05` MCP protocol version rather than releases supporting OAuth 2.1 authorization, introduced in March 2025. Organizations should inventory internet-facing MCP endpoints, restrict public exposure, require authorization before tool execution, apply least-privilege permissions to connected backend credentials, and retain agent prompt and tool-invocation logs for detection and investigation.
Sep 3, 2026
Threat actors have exploited overly permissive anonymous-user settings in publicly accessible **Salesforce Experience Cloud** environments to retrieve data through the `/s/sfsites/aura` endpoint. A modified version of the open-source Aura Inspector tool has been used to mass-scan sites and extract records where guest permissions permit access; exposed names and phone numbers can support subsequent phishing and vishing. Salesforce says the platform is not itself vulnerable—the exposure results from customer configuration—and Dutch authorities reported that these campaigns affected misconfigured environments from late 2025 into early 2026. Researchers also identified multiple **Mendix** low-code applications with excessive rights assigned to anonymous or newly registered users. Automated scans and legitimate platform requests can collect sensitive data from such deployments, potentially enabling extortion; McGraw-Hill was cited publicly as an example in April 2026. Organizations should inventory internet-facing applications and access rights, enforce least privilege and private defaults, remove unnecessary anonymous access and self-registration, require MFA for administrators, and centralize logging and behavior-based detection for abnormal API activity.
Aug 31, 2026