Investigation Reveals Critical Security Gaps On Thousands of Servers Affecting Organisations Across Games, Healthcare, Finance, Government, Automotive & More Focusing specifically on publicly accessible Perforce (“P4” aka “Helix Core”) instances, this security research reveals critical vulnerabilities stemming primarily from insecure default configurations. An investigation into the security of public Perforce instances identified over 6,100 such instances with alarming security gaps: The default Perforce settings allow unauthenticated users to create accounts, list existing users, access passwordless accounts, and until version 2025.1, allowed syncing repositories remotely; potentially exposing intellectual property across more than a dozen sectors including gaming, healthcare, automotive, finance, and government. Action is recommended for all Perforce administrators to ensure security hardening, including setting stronger authentication requirements, disabling automatic account creation, and raising security levels. To secure a perforce server, update to the latest p4 server and ensure any security related configurables are set to theirvendor recommended settings. Better yet,read the security chapter in the documentationto fully understand the implications of the settings you adjust. Perforce is committed to securing their product & their customers. They've patched the most insidious of the defaults, the hidden read-only "remote" user and have published documentation on updated recommended security settings. The venerable Perforce ("P4", the software FKA "Helix Core") is aVersion Controlcornerstone not just ofgames and entertainmentbut of wider engineering industries, including film & VFX, automotive, aerospace, medical devices, industrial automation, and financial services. It's chosen forseveral good reasons: However, out-of-the-box, the security settings are abysmal and securing it requires the adjustment of9settings to bring deployments in line with vendor recommendations. In fact, the majority of the public Perforce servers detected have at least one misconfiguration that allows full access to source code or worse, such as Remote Code Execution (RCE). Source code and assets are the crown jewel of any company that develops software. It contains trade secrets, and potentially credentials in the way of account passwords or API keys. Note: In this article, 'Perforce', 'Helix Core' and 'P4' are used interchangeably. Out of the box,Perforce creates accounts for new users automatically if there is a free license on the server. An example using the Perforcecommand line client,p4: This can be fixed by modifying the"dm.user.noautocreate"configurable to "2": Technical note:If LDAP authentication is set as the default auth method,dm.user.noautocreateis set to "2" implicitly. Attackers can use this to find accounts with no password, or brute-force accounts with weak passwords. For example, an attacker can run the following and get a nice user listing. An interesting quirk of Perforce is that under some configurations, if you guess a valid username, you can retrieve the user listing without knowing the password for the account! This is particularly dangerous when combined with brute-force or the next misconfiguration. It's not particularly hard to guessausername; think about common accounts you'd find at any software company: Example:
A critical exposure of Perforce (Helix Core) source code servers stems from insecure default configurations, including automatic user account creation and weak authentication, allowing unauthenticated access to repositories. The vulnerability, present in versions prior to 2025.1, was partially mitigated by Perforce's removal of the hidden "remote" user in that release. Administrators must immediately harden configurations by disabling automatic account creation (`dm.user.noautocreate=2`), enforcing strong authentication, and consulting Perforce's updated security documentation.