Authenticated Remote Code Execution in FreePBX Music on Hold (MoH) Module

Blog Security
, , , ,
1

Summary

The FreePBX Music on Hold (MoH) module contains a critical security flaw that allows authenticated attackers to execute arbitrary system commands with the privileges of the Asterisk service.

Authentication with an existing FreePBX administrator account is required.

Common Vulnerabilities and Exposures (CVE)

CVE-2026-45562

Provider Urgency (choice of: Not Defined, Clear, Green, Amber, or Red)

A - Amber

Link to Published GitHub Security Advisory (GHSA) with More Details

Highlights

Users that need specific executables not found in the new allowed list of applications may wish to fork and customize this module for their particular environment and/or modify the custom music on hold configuration files generated by the module.

Provider Urgency is set to Amber because this is a potentially breaking change for an extremely small subset of users with custom apps.

:warning: AGAIN, THIS IS A POTENTIAL BREAKING CHANGE FOR AN EXTREMELY SMALL SUBSET OF USERS.

2

specific executables not found in the new allowed list of applications may

How about you make that list known, it is not currently obvious where it is :slight_smile: or do you not know yourself?

3

Great question. Documenting procedure generically enough to hopefully help the next person find this information…

Step 1

Go to the module: GitHub - FreePBX/music: Module of FreePBX (Music on Hold) :: Uploading and management of sound files (wav, mp3) to be used for on-hold music. ¡ GitHub

Step 2

Click on the button that says: :watch: 456 Commits

That should open this link: https://github.com/FreePBX/music/commits/release/17.0/

Step 3

Scroll back thru some of the most recent commit messages and click on them, for example: FREEI-2858 Changes done for fixing MoH application field vulnerability ¡ FreePBX/music@2b13670 ¡ GitHub

Step 4

Inspect the commit, and in this case, you might see the allowed list of apps:

	'/usr/bin/mpg123',
	'/usr/local/bin/mpg123',
	'/usr/bin/mpg321',
	'/usr/local/bin/mpg321',
	'/usr/bin/madplay',
	'/usr/local/bin/madplay',
	'/usr/bin/ogg123',
	'/usr/local/bin/ogg123',
	'/usr/bin/cvlc',
	'/usr/local/bin/cvlc',
4

Is there some attack vector here I’m missing other than that one could set any shell command for the MOH source?

How is that different from using the Config Edit module and adding a System() call to dialplan?

Or defining a custom email command for voicemail?

These aren’t vulnerabilities, they are functions an admin should be able to do if they have the credentials to do them.

5

Good questions – this is potentially some change afoot for well-versed admins such as yourself :cowboy_hat_face:

  • First, regarding MOH specifically: Not every user with permission to change the radio station dial for music on hold via the GUI should also be able to run arbitrary shell commands as the web server.

  • Config Edit is on another level, but, it still could use a look into ways of helping web admins avoid shooting themselves in the foot – that’s what SSH is for! :grin: And indeed it does try a bit – and has done for a long time – w/r/t stopping edits of FPBX-generated files.

  • Custom email command setup for voicemail is worth considering some limits, too. What are your thoughts on requiring this be done only via SSH and not the GUI ?

6

This is a hat on a hat that offers zero security benefits. It doesn’t secure anything considering that there’s zero validation on if they exist, don’t exist or haven’t been touched.

Say madplay is actually installed at /usr/local/bin/madplay, having /usr/bin/madplay that doesn’t exist is pointless. Not only that I can just create my on /usr/bin/madplay with all the bad stuff in it I need to do and it will pass your “security” check for this part.

All this does is breaks existing usage expectations and current deployments for zero security benefits.

7

Would have been better just to eliminate the option and include a migration in the install script that will move any custom MOH program definitions to the _custom file so that they don’t break.

@penguinpbx it is ok to say “working as designed” to security researchers that point out that a field allows for shell scripts… that is, in fact, the point of the field…

I disagree, would basically break every integration that uses this field, since in probably every case it’s a custom-written script with a name you cannot predict.

8

The “working as designed” AKA “feature not bug” response is often not well-received, with a list of CVE rules attached as footnotes in some cases.

Shifting to dangerous mode only available from command line seems more appropriate in most cases. Case in point is this topic – not a lot of feedback here (yet) from negatively affected users of this potentially breaking change, nor is it showing up in GitHub issues AFAICT.

Regarding voicemail, and really any custom command execution, that typically requires shell access to add new commands (or module installation – separate concern there as well). But from the GUI, a safeguard like only allowing letters or digits through as parameters to said commands was more of the direction to take this. FreePBX code can’t predict the name but it can (probably) predict the range of characters allowed for the name and the parameters.

9

The ‘working as designed’ claim is accurate since is describes what this feature actually does. This is a documented Asterisk feature not some undiscovered ability. This isn’t about being able to run shell commands because that’s what it’s supposed to do. This is about if an authenticated admin user has the ability to configure any meaningful attack vectors beyond what their permissions and authentication let them do in other areas like _custom.conf, etc..

Sangoma’s own advisory has the CVSS v4.1 published as 0.7/Low, which basically says ‘given real-world deployment scenarios, this barely represents additional risk.’ That’s a score Sangoma gave this on a advisory with a severity of HIGH. Both cannot be true at the same time.

If this is ‘more appropriate’, then you’re acknowledging the feature itself is legitimate admin functionality that was scoped too aggressively in the fix, not a vulnerability that needed to be closed. That’s the ‘working as designed’ argument, just with a different dress on.

Plus this “fix” leaves the _custom.conf file completely open, untouched, unvalidated and completely usable by an admin with the same authentication and permissions. If this was a real RCE that gap would matter. The fact it’s not in the advisory either means Sangoma didn’t consider it or Sangoma found it was a legitimate admin function.

These are horrible metric points. This project has a history of things being under reported, not to mention some people may not have updated the module or the best one, they were affected and saw this thread, etc and just moved their MoH configs to musiconhold_custom.conf to fix the issue. You know, the thing they were able to do before the update. So not having feedback or a github issues does not equate “No one is impacted by this”.

10

Not well-received by whom? The rando new Github account that used an AI scanning tool to raise the low-impact CVE? :man_shrugging: I’d say take a poll…

If fields that accept system commands are a concern, then go all-in or all-out. The modules that come to mind are Advanced Settings (a whole bunch of fields specifying paths to executables), Sysadmin (postfix custom config), Voicemail Admin (custom email command), MOH, Config Editor. If I hunted through FreePBX I would probably be able to find more, though my point here is that it’s not a small thing to declare that fields accepting system commands are a CVE-worthy security concern.

Maybe it would be better to offer a finer-grained permissions set for admins. Super-admins can set fields that specify system commands. Normal admins can do everything else an admin can do except manipulate those fields.

11

Not only that there’s a 7 point swing in the CVE scores which is highly unusual. It has a severity of HIGH which is the story headline but buried in the story is the 0.7 score which represents the actual real world impact of the issue. Along with keeping all the other gaps open that would allow for this RCE to still happen shows that Sangoma knows this issue isn’t as severe as they are making it out to be. The entire CVE is questionable.

12

Hero mode here we come!

:superhero:

On deck for v18 is migration to User Manager completion, so this fits with that goal, exact nomenclature TBD.

Agreed and some of the rationale is discussed in Watch what we do with security fixes :eyes:

13

I’m not sure this helps you the way you think it does. You published a CVE with a headline of “Severe:High” Score 7.6 / 10 when that was highly incorrect. It’s over dramatizing this as “Highly Serve RCE in FreePBX” when it’s not. It’s just not.

– GitHub gave it a base score of 7.6
– Sangoma applied TES to the base and gave it a 4.9. That 4.9 isn’t auto generated, Sangoma gave it that score manually.
– Then you @penguinpbx , as that blog post highlights, to fix what you consider broken CVSS PR apply your own calculations to consider additional factors for PR. The blog post claims “to control more of the final score.” Your own calculations of a better controlled final score was 0.7.

Basically your own TES based scoring reduced it from High to Medium and your own proposed fix calculates this as a 0.7 or Low. You published a CVE with a dramatized and sensationalized headline and score that wasn’t accurate and unless you actually review the CVE instead of looking a summary of titles, you’ll never know it’s actually a “Low Severity RCE that will probably never happen” thing. This is my issue with this CVE, it’s filled with contradictions such as a PU of Amber which means “Yeah do this when you can, no rush but don’t not do it” but again flagged as a “High” which generally should be a PU of Red as in “do this ASAP, you’re exposed if you don’t” .

I haven’t done a bigger review of the other CVE’s you’ve posted but on the surface they didn’t stand out like this one. I’m hoping that stands true when I go through them more.

14

Please do review the work, thank you. I also recommend you review the scoring tools provided by GitHub in your own module repo security reporting configuration. Then compare that subset with the larger set of knobs available as part of the complete CVSS 4.0. Any of the recent several Blog > Security topics/issues are (conveniently) already open for feedback. :frog: