The missedcall module does not properly sanitize the name of the caller when logging it to the database.
Provider Urgency is set to Amber for most users of this module. Please take action immediately if you use this module.
Requested
GHSA-g27h-xf3q-h3rm
Things like this make me lean towards not using AI for security audits. At a minimum the human using the tools needs to have some idea what the findings mean.
The chain of events to exploit this are so ridiculous that you have better odds playing your local lottery. You should ALWAYS sanitize un-trusted inputs to your database. That said this is not exploitable in the real world nor in most fantasy worlds. This is AI hallucinating a problem in an attempt to make the user happy.
The Mitigations section of the GHSA includes (in part):
- Allow inbound call access by only known, trusted SIP trunks and endpoints.
- Overwrite the Caller ID Name as soon as possible in your incoming call flow with custom dialplan or modules e.g. Superfecta (not tested.) Conversely validate the output of any manipulations done by other dialplan/modules.
- Configure SBCs in front of FreePBX to filter your traffic and sanitize the
Fromlines.
However, there’s probably some users caught up in the above scenarios 
and it is doubtful there will be a show of af/infected hands any time soon.
Trying to work this acronym into the lexicon – starting with myself – but if you agree, maybe you can help:
Validate Inputs and Sanitize Outputs Always People (VISOAP)
Stealing SIP user/pass AKA toll fraud (it happens!), camping out on an IP that has access to the PBX, waiting for a bad firewall config by the operator, launching MITM on unencrypted UDP are just a few examples of some “real world” stuff that could get you in trouble if this issue is left unpatched.
Related, the Asterisk project issues security advisories for things in this general orbit similarly e.g. Remote DoS and possible RCE in asterisk/res/res_stir_shaken/verification.c · Advisory · asterisk/asterisk · GitHub