CVE-2026-46376 is a critical vulnerability in the FreePBX User Management module that can allow an unauthenticated attacker to access the User Control Panel when a specific deployment condition is present: an administrator previously enabled the optional UCP generic-template workflow and the initial template credentials were never properly changed.
That qualification matters.
This is not a vulnerability where every reachable FreePBX installation automatically accepts a universal password. The vulnerable state depends on an administrative workflow having been executed first. But when that condition exists and UCP is reachable from an attacker-controlled network, what looks like an initialization convenience can turn into an authentication boundary failure.
The official FreePBX security advisory lists the affected userman package as versions below 16.0.45 for FreePBX 16 and below 17.0.7 for FreePBX 17. Those releases contain the remediation. FreePBX currently scores the issue at 9.1 Critical under CVSS v4.0, while NVD displays a 9.8 Critical CVSS v3.1 score.
The distinction between “hard-coded credentials exist” and “every FreePBX server can be compromised” is the central point security teams need to understand about CVE-2026-46376.
CVE-2026-46376 at a glance
| Objet | Détail confirmé |
|---|---|
| CVE | CVE-2026-46376 |
| Produit | FreePBX |
| Affected module | userman |
| Security boundary | User Control Panel |
| Faiblesse | CWE-798: Use of Hard-coded Credentials |
| FreePBX 16 affected versions | userman below 16.0.45 |
| FreePBX 16 patched version | 16.0.45 |
| FreePBX 17 affected versions | userman below 17.0.7 |
| FreePBX 17 patched version | 17.0.7 |
| Authentication required from attacker | No, when the vulnerable template state exists |
| Additional deployment condition | UCP generic-template setup must previously have been used |
| FreePBX CVSS v4.0 | 9.1 Critical |
| NVD CVSS v3.1 | 9.8 Critical |
| CWE | CWE-798 |
| PoC public | Oui |
| Primary remediation | Update userman and restrict UCP/ACP exposure |
The FreePBX advisory was published on May 15, 2026. NVD published CVE-2026-46376 on May 29. FreePBX also states that the underlying behavior was introduced in 2021 as part of the UCP functionality.
What CVE-2026-46376 actually affects
CVE-2026-46376 sits in a somewhat unusual place in the FreePBX architecture.
It is not primarily an Asterisk SIP parser vulnerability. It is not an unauthenticated SQL injection into the FreePBX Administrator interface. It is not a Linux kernel issue, and the official advisory does not describe it as direct remote command execution.
The affected component is FreePBX User Managementou userman.
Sangoma’s documentation describes User Management as the module responsible for managing users and administrators across services including UCP. It can associate users with extensions and control which resources they can reach. A user can, depending on configuration, even be granted access to resources belonging to multiple extensions.
The vulnerability appears in an optional workflow intended to simplify deployment of common UCP configurations.
According to the FreePBX advisory, the generic-template setup process used hard-coded sample credentials. An administrator first needed authenticated access to the Administrator Control Panel to perform the initial setup. After that setup occurred, however, the static initialization credentials could remain usable unless additional administrative action was taken.
That creates the vulnerable transition:
authenticated administrator setup → reusable template identity → unchanged initialization credential → potentially unauthenticated UCP access
The important point is that the bug changes the security properties of an account after legitimate administrative configuration.
It is therefore more accurately understood as an unsafe credential lifecycle problem than as a conventional password brute-force weakness.
The attack requirement that changes the risk calculation
A lot of vulnerability summaries reduce CVE-2026-46376 to something like:
FreePBX contains hard-coded credentials that allow unauthenticated UCP access.
Technically, that sentence omits the most important constraint.
The official advisory says the affected behavior belongs to an optional process administrators may choose to run to simplify common UCP deployments. The administrator must first configure the generic UCP templates. Only systems where that state was created can expose the relevant credential path.
A useful exposure model is therefore:
Reachable UCP
Affected userman version
Generic UCP template workflow previously initialized
Old credential state still valid
=
Candidate CVE-2026-46376 exposure
Finding only the first two conditions is not sufficient proof.
This has practical implications for vulnerability management. A scanner may accurately identify a FreePBX version below the patched release while still being unable to determine whether the vulnerable administrative workflow was ever executed.
Conversely, a security team may see no obvious suspicious behavior in the main FreePBX Administrator interface while an old UCP template account remains exposed.
CVE-2026-46376 therefore illustrates why version detection and exploitability validation are different jobs.
Why the CVSS scores look different
CVE-2026-46376 also demonstrates a useful limitation of reducing vulnerability priority to one number.
The FreePBX advisory currently assigns a CVSS v4.0 Base Score of 9.1 Critical with the following major properties:
- Network attack vector
- Low attack complexity
- Attack requirements present
- No attacker privileges required
- No user interaction
- High vulnerable-system confidentiality impact
- High vulnerable-system integrity impact
- No vulnerable-system availability impact
The critical detail is Attack Requirements: Present.
FreePBX’s scoring reflects the fact that the target must already be in the specific vulnerable state created by the optional UCP template workflow.
NVD also displays a 9.8 CVSS v3.1 score, using a vector with network reachability, low complexity, no required privileges and no user interaction. CVSS v3.1 does not express the same attack-requirements concept in exactly the same way as CVSS v4.0.
This does not mean one database says the bug is critical and the other says it is harmless.
Both treat it as a serious vulnerability.
But for defenders, the operational equation should be more specific:
severity × exposure × configuration state × privilege scope × evidence of exploitation
A vulnerable internet-reachable UCP where the template workflow was used deserves very different treatment from an internal FreePBX deployment where the feature was never configured.
What the vulnerable design did wrong
The root security failure is conceptually straightforward.
Secrets used during provisioning must either be unique, temporary, or removed once initialization is complete.
Hard-coded credentials violate that assumption because the secret is determined by the software rather than the deployment.
That transforms the secret from:
something the administrator knows
into:
something anyone who knows the implementation may know
The problem becomes much worse when the credential is shared across installations.
FreePBX states that hard-coded sample credentials were used during the generic UCP template setup process. Its advisory says updating userman changes the behavior so that the password is randomized.
That change is important because randomization changes the security model from:
one software-known secret → potentially many installations
à :
one independently generated secret → one installation
Even if both accounts serve the same functional purpose, their resistance to credential reuse attacks is fundamentally different.
Why a UCP compromise matters
The term “User Control Panel” can make the vulnerability sound less serious than a FreePBX Administrator compromise.
That is misleading.
UCP is intentionally designed to let users interact with telephony resources.
Sangoma documents UCP modules and capabilities including call history, voicemail, fax, presence, settings, SMS, conferencing and WebRTC functionality. Access is controlled through User Management permissions.
The voicemail interface, for example, can display voicemail metadata and allow users to listen to and download voicemail messages associated with their extension.
Other documented UCP functionality includes call forwarding, Do Not Disturb, call waiting and other phone features.
Depending on the modules installed and permissions granted, a compromised UCP identity can therefore affect considerably more than the visual appearance of a dashboard.
Possible consequences can include exposure or modification of:
| UCP resource | Potential security concern |
|---|---|
| Voicemail | Sensitive voice messages and caller information |
| Call history | Internal and external communication metadata |
| Contact information | Employee, customer or business contact data |
| Call forwarding | Manipulation of how inbound communications are routed |
| Phone settings | Changes to user telephony behavior |
| Fax features | Exposure of fax-related information when enabled |
| Endpoint-related settings | Configuration changes where appropriate permissions exist |
| Presence information | Operational information about user availability |
The exact impact depends on permissions.
That qualification is essential: CVE-2026-46376 does not automatically grant every possible UCP permission.
FreePBX User Management controls what a user can access. Therefore, the blast radius of successful exploitation is partly determined by how the affected template identity was configured.
A VoIP control plane should not be treated like an ordinary website
The security significance becomes clearer when FreePBX is viewed as communications infrastructure rather than simply PHP software with a web interface.
A PBX can sit in the operational path between employees, SIP endpoints, trunks, voicemail, support lines and external callers.
That makes several categories of data unusually valuable.
A voicemail may contain customer information, temporary credentials, internal discussions or executive instructions.
Call history can reveal business relationships and communication patterns.
Forwarding controls influence where calls terminate.
Contacts may expose information useful for social engineering.
A compromised communications account can also support attacks that happen outside the compromised server itself.
This is why reducing CVE-2026-46376 to “someone might see a user portal” understates the risk.
At the same time, describing it as “instant root on every FreePBX server” overstates it.
The correct security assessment lies between those two extremes.
CVE-2026-46376 attack path
At a high level, a realistic attack path looks like this:
1. Discover FreePBX
An attacker identifies a FreePBX deployment whose UCP is reachable from an untrusted network.
↓
2. Identify a candidate vulnerable release
The exposed system or other observable information suggests a userman version below the fixed release.
↓
3. Determine whether generic-template state exists
The vulnerability requires the optional template workflow to have previously been initialized.
↓
4. Attempt authentication using publicly known implementation information
Because the historical initialization material was embedded in publicly available software, an attacker does not need to guess a per-organization secret when the vulnerable state remains present.
↓
5. Obtain a UCP session
Successful authentication crosses the UCP authentication boundary.
↓
6. Enumerate granted UCP permissions
The attacker discovers which voicemail, calling, contact, device or other functions the identity is permitted to reach.
↓
7. Abuse accessible communications functionality
Impact is determined by the privileges assigned to the compromised identity and by other vulnerabilities that may exist on the system.
The hard-coded credential itself is deliberately not reproduced here. Defenders do not need to place a reusable credential into production validation scripts to determine whether they are at risk.
Public PoC changes the threat environment
CVE-2026-46376 is no longer only a theoretical advisory.
A public proof of concept was published in July 2026 that automates checks against vulnerable FreePBX UCP installations. The public archive identifies FreePBX 16 userman through 16.0.44 and FreePBX 17 through 17.0.6 as vulnerable candidates and references the fixed 16.0.45 and 17.0.7 releases.
The existence of public exploit code changes the operational risk.
An attacker no longer needs to independently inspect years of FreePBX source history and construct the authentication flow from scratch. The implementation knowledge required to test the vulnerability has been packaged publicly.
But a public PoC is not equivalent to confirmed exploitation in the wild.
NVD’s CVE history includes CISA ADP SSVC metadata recorded on May 29, 2026 with exploitation: none, while marking the issue automatable and assigning high technical impact.
That creates an important distinction:
Public exploitability: confirmed.
Public PoC: confirmed.
Mass exploitation campaign: not established by the primary sources reviewed here.
Confirmed inclusion in CISA KEV: not established by the sources reviewed here.
Defenders should patch without waiting for KEV status. A vulnerability does not become technically exploitable only after government agencies observe exploitation.
Do not confuse CVE-2026-46376 with the other 2026 FreePBX UCP vulnerabilities
FreePBX has disclosed several security issues during 2026, and combining them into one exploit story can produce inaccurate reporting.
One particularly important example is a separate authenticated command injection vulnerability in the FreePBX UCP interface, disclosed in June 2026.
FreePBX described that issue as allowing users who are already authenticated to UCP to execute arbitrary commands as the web-server user through specially crafted HTTP requests.
The Canadian Centre for Cyber Security also highlighted the corresponding FreePBX UCP updates in its June advisory.
This matters because authentication-bypass and post-authentication vulnerabilities can sometimes become dangerous combinations.
But security teams should not casually write:
CVE-2026-46376 = unauthenticated RCE
That conclusion does not follow from the CVE-2026-46376 advisory itself.
The defensible statement is narrower:
CVE-2026-46376 can provide unauthorized UCP authentication under the documented configuration conditions. A vulnerable system may contain other UCP or FreePBX vulnerabilities that increase post-authentication impact, so all modules—not only userman—should be reviewed and updated.
That distinction is important for accurate incident response.
How to check whether your FreePBX system is affected
The safest validation process starts with state collection rather than exploitation.
Step 1: Check the installed module version
On an authorized FreePBX host, inspect installed modules:
fwconsole ma list
You can narrow the output:
fwconsole ma list | grep -i userman
The critical patched levels identified by the FreePBX advisory are:
FreePBX 16:
userman 16.0.45 or later
FreePBX 17:
userman 17.0.7 or later
Anything below those versions should trigger further investigation.
Do not rely only on the broad FreePBX platform version.
The advisory identifies the affected package as userman, so module-level inventory is the more precise signal.
Step 2: Determine whether UCP is reachable
From an authorized network location, determine whether the UCP service is exposed.
A simple HTTP header request can establish reachability without testing authentication:
curl -I https://pbx.example.com/ucp/
You can also perform a limited service inventory:
nmap -sT -p 80,443 --script http-title pbx.example.com
This establishes attack-surface exposure.
C'est le cas pas prove CVE-2026-46376.
Step 3: Identify who can reach UCP
Check network controls around:
- the public internet;
- employee networks;
- remote-access VPNs;
- MSP networks;
- administrator networks;
- voice VLANs;
- site-to-site VPNs;
- cloud security groups;
- reverse proxies.
FreePBX explicitly recommends denying ACP and UCP access from hostile networks and points administrators toward the FreePBX Firewall module.
The firewall documentation also shows that FreePBX can treat known registered endpoints specially when deciding whether UCP access should be permitted, giving administrators a way to avoid exposing the interface universally.
Step 4: Determine whether the generic-template feature was ever used
This is one of the highest-value questions.
Because the vulnerability depends on the template setup having previously been run, organizations should review:
- UCP deployment documentation;
- PBX administrator change records;
- User Management configuration;
- template-related identities;
- database state;
- backups;
- historical administrator activity.
A system below the patched version where the workflow was never initialized has a different risk state from a system where it was used.
Step 5: Review UCP identities
Security teams should inventory users and groups with UCP access.
Look for:
- template-related identities;
- unexpected users;
- users with unusually broad resource access;
- stale accounts;
- accounts associated with former employees;
- accounts mapped to multiple extensions without a business reason;
- administrative or template identities used interactively.
Because FreePBX User Management controls both identities and permissions, this step helps establish the possible blast radius.
Hunting for attempted or successful exploitation
After identifying an exposed vulnerable system, version remediation alone may not be enough.
An administrator should determine whether someone used the vulnerable authentication path before the patch was applied.
Start with web and UCP authentication logs.
Search for suspicious access to UCP endpoints:
grep -Rni "/ucp" /var/log/httpd/ /var/log/apache2/ 2>/dev/null
Exact log locations vary by FreePBX distribution and deployment, so administrators should adapt paths accordingly.
Next, correlate:
- source IP;
- timestamp;
- HTTP method;
- authentication result;
- session creation;
- subsequent UCP requests;
- account identity;
- related voicemail or call-management activity.
Pay particular attention to authentication by identities that normally exist only for configuration or template purposes.
The public PoC archive specifically identifies successful logins involving the template-creation identity as a useful detection signal.
Security teams do not need to replay the public credential against production to investigate this.
Historical authentication evidence is safer and often more valuable.
Why successful authentication deserves incident-response treatment
Suppose a vulnerable account was successfully used from an unknown internet address.
Patching the module closes the vulnerability going forward, but it does not answer what happened while the attacker had a valid UCP session.
The next investigation should determine:
What did the compromised identity have permission to access?
Then:
What actions occurred during the suspicious session?
Depending on installed modules, review:
- voicemail access;
- voicemail downloads;
- contact access;
- forwarding changes;
- call-setting changes;
- endpoint configuration;
- user-management changes;
- unusual WebRTC behavior;
- fax access;
- SMS functionality;
- authentication changes.
Sangoma’s documentation shows that UCP can expose voicemail and calling-related functionality, while administrator-controlled User Management determines the resources associated with each user.
A successful unauthorized login should therefore be evaluated as a potential communications-security incident rather than closed as a simple failed-login problem.
Patch CVE-2026-46376 correctly
The primary remediation is straightforward:
FreePBX 16
Mise à niveau userman à 16.0.45 or later.
FreePBX 17
Mise à niveau userman à 17.0.7 or later.
FreePBX says the updated module randomizes the password used by the affected workflow.
Security teams should normally update to the latest supported module release rather than stopping at the exact first patched release.
That matters particularly for FreePBX because CVE-2026-46376 is not the only security issue disclosed across FreePBX modules in 2026.
After updating:
fwconsole ma list | grep -i userman
Confirm that the active installed module reflects the expected version.
Do not mark the ticket complete merely because the update command returned successfully.
Network isolation remains necessary after patching
The official remediation also contains an architectural lesson.
FreePBX recommends ensuring only authorized users can access ACP and restricting ACP/UCP access from hostile networks, including through the FreePBX Firewall.
That recommendation should survive beyond this particular CVE.
A strong deployment model looks closer to:
Internet
|
X
|
Public access to FreePBX management blocked
|
VPN / trusted access
|
Management network
|
+---------------------------+
| FreePBX |
| |
| ACP -- trusted users only |
| UCP -- scoped access |
| SIP -- required peers |
+---------------------------+
Telephony often requires some internet-reachable services.
That does not mean every FreePBX management surface should inherit the same exposure.
The ideal policy is not:
PBX must receive calls, therefore the PBX web interface must be public.
Those are separate requirements.
Firewall controls for FreePBX UCP
FreePBX includes a firewall specifically designed around VoIP deployment requirements.
Sangoma’s documentation explains that the firewall understands concepts such as known trunks, peers and registered endpoints rather than treating the server as an ordinary generic web host.
This makes it possible to build tighter UCP exposure policies.
Security teams should review:
- Internet zone rules;
- trusted-zone definitions;
- local network classifications;
- registered endpoint behavior;
- administrative subnets;
- VPN access;
- unnecessary management ports.
Be cautious with broad “trusted” networks.
An entire corporate LAN does not automatically deserve unrestricted PBX management access simply because it is internal.
Modern attack paths frequently originate from compromised internal endpoints.
MFA helps, but it does not fix hard-coded credentials
The FreePBX advisory recommends stronger administrator protection through mechanisms such as MFA or SAML where appropriate.
Those controls are valuable.
But it is important to understand their role.
MFA does not make an old vulnerable userman release safe.
Network restrictions do not make a hard-coded credential disappear.
A strong password on the primary administrator account does not change the password embedded in another authentication workflow.
The correct remediation hierarchy is:
patch the vulnerable behavior first
then
remove unnecessary exposure
then
strengthen authentication
then
monitor the resulting identity boundary
Layering compensating controls around vulnerable software is useful during emergency response, but it should not become a substitute for the vendor fix.
Safe validation is better than production exploitation
Once public PoCs exist, security teams are often tempted to validate vulnerabilities by simply executing the exploit against production.
That can be unnecessary.
For CVE-2026-46376, a defensible validation process can establish most of the required facts without authenticating with the published hard-coded credential.
Collect:
Installed userman version
+
Whether UCP is reachable
+
Whether generic templates were initialized
+
Whether the template identity exists
+
Whether historical authentication occurred
+
Current permissions assigned to the identity
That evidence is usually enough to establish whether the system needs urgent remediation.
If exploit-level verification is required for an authorized penetration test, use an isolated reproduction or controlled staging environment wherever possible.
The objective should be demonstrating the security condition—not unnecessarily creating new attacker-like sessions inside a production phone system.
Using agentic pentesting for CVE validation
CVE-2026-46376 is also a useful example of where security validation requires more than matching a version string.
A scanner can determine that userman is below 16.0.45 or 17.0.7.
An actual validation workflow needs to reason about several additional conditions:
Version vulnerable?
|
v
UCP reachable?
|
v
Template workflow used?
|
v
Affected identity present?
|
v
Historical suspicious login?
|
v
What permissions were exposed?
For organizations using automated or agentic penetration-testing workflows, the useful role of automation is orchestrating those evidence-gathering steps rather than simply launching every public PoC.
For example, Penligent can coordinate authorized security-tool execution and evidence collection across vulnerability-verification tasks. Its documentation describes an agentic testing workflow and its product supports security tool orchestration and CVE-focused validation.
For CVE-2026-46376, a responsible automated workflow should favor module enumeration, surface discovery, configuration validation and log evidence before active authentication testing.
Automation should reduce uncertainty—not increase production risk.
CVE-2026-46376 vs CVE-2025-57819
FreePBX defenders may also encounter searches comparing CVE-2026-46376 with the heavily discussed CVE-2025-57819.
They should not be treated as the same class of vulnerability.
CVE-2025-57819 affected the Endpoint Manager module and could lead to unauthenticated Administrator access, database manipulation and remote code execution under vulnerable conditions. It was also associated with observed exploitation against exposed FreePBX deployments.
CVE-2026-46376 is different.
| Characteristic | CVE-2026-46376 | CVE-2025-57819 |
|---|---|---|
| Primary component | User Management / UCP | Endpoint Manager |
| Root issue | Hard-coded initialization credentials | Input-handling/authentication weaknesses |
| Initial attacker privileges | None under required template state | Aucun |
| Primary immediate impact | Unauthorized UCP authentication | Administrator-path/database compromise |
| Direct RCE stated by advisory | Non | Oui |
| Configuration dependency | Generic UCP template previously initialized | Different exposure conditions |
| Main defense | userman update + UCP isolation | Endpoint update + management-plane isolation + compromise investigation |
The comparison reinforces an important operational lesson.
FreePBX should be managed as an evolving collection of modules and attack surfaces, not as one version number.
A PBX can have a patched userman module but an outdated endpoint module.
Or the reverse.
Security teams need module-level inventory.
Patch prioritization for enterprise FreePBX environments
Not every candidate system requires the same response order.
A practical priority model is:
| Condition | Priorité |
|---|---|
Vulnérable userman + public UCP + template workflow used | Emergency |
Vulnérable userman + externally reachable through VPN/MSP network + template used | Critique |
Vulnérable userman + internal UCP + template used | Haut |
| Vulnerable version but template use unknown | High until verified |
| Vulnerable version, feature confirmed unused, UCP isolated | Patch promptly |
Fixed userman, exposed UCP | Harden exposure |
Fixed userman, restricted UCP, no suspicious evidence | Normal monitoring |
The highest-risk systems are not simply those with the oldest version.
They are the systems where vulnerability state and attacker reachability intersect.
What security teams should monitor after remediation
After the immediate patching cycle, add FreePBX to regular identity and exposure monitoring.
At minimum, continuously track:
- installed FreePBX module versions;
- public management exposure;
- firewall configuration;
- UCP and ACP authentication;
- privileged identity changes;
- unusual template accounts;
- forwarding changes;
- voicemail-access anomalies;
- high-risk module security advisories.
This is particularly important for PBX systems because they can remain stable for years.
Operational stability can create security complacency.
A phone system that has “worked fine since 2021” may still contain security-relevant state created by a historical initialization process.
CVE-2026-46376 is almost a textbook example of that problem: FreePBX traces the vulnerable behavior back to a feature introduced in 2021, while the advisory was not published until May 2026.
The broader lesson: initialization secrets are production secrets
The deepest lesson from CVE-2026-46376 has little to do with VoIP.
Temporary credentials often become permanent credentials.
Installation passwords become forgotten accounts.
Bootstrap tokens remain in databases.
Default secrets survive automation.
Migration identities are never deleted.
Template users become real authentication principals.
Developers may think:
“This account only exists to make initial configuration easier.”
Attackers think:
“Does this account still authenticate?”
Any bootstrap credential that can cross a production authentication boundary must be treated as a production secret.
A safer lifecycle looks like:
Generate unique secret
|
v
Perform bootstrap operation
|
v
Rotate or destroy credential
|
v
Verify bootstrap account state
|
v
Log lifecycle completion
The vulnerable pattern looks like:
Embed reusable secret in software
|
v
Create production identity
|
v
Assume administrator will replace it
|
v
Credential survives
|
v
Software becomes public documentation
That final step is crucial.
Open-source software makes implementation details observable by design.
Security cannot depend on attackers failing to read the source code.
Frequently Asked Questions
What is CVE-2026-46376?
CVE-2026-46376 is a critical hard-coded credentials vulnerability affecting the FreePBX userman module. Under the documented vulnerable configuration, an unauthenticated attacker may be able to access the FreePBX User Control Panel using credentials associated with the UCP generic-template setup process.
Which FreePBX versions are affected by CVE-2026-46376?
The official FreePBX advisory lists:
FreePBX 16 userman:
Versions below 16.0.45 are affected.
FreePBX 17 userman:
Versions below 17.0.7 are affected.
The corresponding patched releases are 16.0.45 and 17.0.7.
Is every FreePBX installation vulnerable?
No.
The vulnerable condition depends on the optional UCP generic-template setup having previously been run. FreePBX states that authenticated ACP access is required for the initial template configuration, after which the unchanged initialization credentials could allow unauthenticated UCP access.
Does CVE-2026-46376 provide remote code execution?
The CVE-2026-46376 advisory itself describes unauthorized access to UCP through hard-coded credentials. It does not describe direct RCE as the immediate vulnerability impact.
FreePBX separately disclosed authenticated UCP command-injection vulnerabilities in 2026. Those vulnerabilities should be patched as well, but they should not be inaccurately merged into the definition of CVE-2026-46376.
What is the CVSS score for CVE-2026-46376?
FreePBX’s current GitHub advisory assigns a CVSS v4.0 Base Score of 9.1 Critical.
NVD additionally displays a CVSS v3.1 Base Score of 9.8 Critical.
Why does FreePBX mark Attack Requirements as present?
Because the vulnerable template state does not exist automatically on every installation.
The administrator must previously have run the optional UCP generic-template setup workflow. That environmental prerequisite is reflected by the CVSS v4.0 AT:P valeur.
Is there a public exploit for CVE-2026-46376?
A public proof of concept for the vulnerability was available by July 2026. It automates checks against FreePBX systems that may retain the vulnerable UCP template credential state.
Public PoC availability should not be confused with evidence that every vulnerable FreePBX system is currently being exploited.
How should I safely test CVE-2026-46376?
Start by checking the installed userman version, determining whether UCP is reachable, confirming whether the generic template workflow was used and reviewing historical authentication logs.
For production systems, avoid unnecessarily replaying the publicly known hard-coded credential simply to prove something you can establish through configuration and log evidence.
What should I patch?
Update the userman module to the latest supported version.
At minimum, the FreePBX advisory identifies 16.0.45 for FreePBX 16 et 17.0.7 for FreePBX 17 as the patched versions.
Should UCP be exposed to the public internet?
As a general defensive design principle, management and user-control surfaces should be reachable only by users and networks that need them.
FreePBX specifically recommends blocking hostile networks from ACP and UCP and using the FreePBX Firewall module to control access.
Final assessment
CVE-2026-46376 is serious precisely because the vulnerability is simple.
There is no need for memory corruption.
There is no race condition.
There is no sophisticated cryptographic attack.
The failure is an authentication secret whose lifecycle did not match the security boundary it protected.
Once the optional UCP template functionality had been initialized, a credential intended to simplify deployment could remain valid in a production environment. If UCP was accessible to an attacker, that design could turn implementation knowledge into authentication.
FreePBX fixed the issue in userman 16.0.45 and 17.0.7 by changing the credential behavior, and administrators should move beyond those minimum versions to current supported module releases.
But patching should be only the first action.
Administrators should also determine whether the generic template feature was ever used, review UCP identities and permissions, investigate historical authentication, restrict UCP and ACP to appropriate networks, and update the rest of the FreePBX module stack.
Most importantly, defenders should avoid both extremes in interpreting CVE-2026-46376.
It is pas proof that every FreePBX server can be remotely taken over with one universal password.
It is also pas an insignificant default-password warning.
On the systems where the documented configuration state exists, CVE-2026-46376 represents a genuine failure of the authentication boundary protecting an important part of the VoIP management plane.
That is sufficient reason to identify affected systems, patch them, verify the credential state and investigate any unexplained UCP access before treating the vulnerability as closed.
French 
English 
German 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew