Any authenticated User Control Panel (UCP) end-user, a normal account and not an admin, can read and overwrite Contact Manager entries that belong to other UCP users.
Authentication with a known UCP user is required.
Requested
GHSA-j82w-j6cr-56m6
G - Green
Just FYI, someone may have jumped the gun on something related to the security updates. It’s shouting at me to update but also telling me I’m already up to date!
Assisted-by: Muse Spark 1.3
Hi all — following up on GHSA-j82w-j6cr-56m6 (thanks to mil1200 for the original find): the fix doesn’t appear to have landed on the 18.x line.
On current release/18.0 HEAD, ucp/Contactmanager.class.php (~line 231, delimage handler, the elseif (!empty($_POST['image'])) branch) still does:
unlink($this->cm->tmp."/".$_POST['image'].".png");
No ownership check, no basename() — the exact sink the advisory describes. The 17.0 fix for this hunk is commit af826f6d (FREEI-3078, shipped in 17.0.8), which changed it to basename($_POST['image']); that hunk never made it to 18.x (the corresponding 18.0 commit, 6b122bab, covers the id/owner-check branch only).
Verified end-to-end on release/18.0 branch HEAD (18.0.1 module version; assembled from public branch tips in a disposable lab — no 18.0 distro release published at time of testing): an authenticated low-privilege UCP user, with no admin rights and no victim interaction, deleted an asterisk-writable .png outside the temp directory and got {"status":true} back. The published advisory lists affected/patched versions for 16.x and 17.x only, so 18.x looks like a backport gap rather than an intentional exclusion.
Suggested fix: port the one-word basename() hunk from af826f6d to release/18.0. Happy to test a candidate build or provide a diff.
Not sure if that is a temporary mirror hiccup or something else yet… thanks for the heads up.
Good catch. We haven’t released v18 yet so there are some things to merge since the branch was cut – still pre-ALPHA at this point though.
Sure, but there was a commit that claimed to fix this issue, but didn’t 100%, so that’s why there’s a concern. Just wanted to give a heads up before release, ya know?
@tomk Thanks a lot for flagging this and giving us the heads-up—we really appreciate the community keeping a close eye on security details like this.
As @penguinpbx mentioned, v18 hasn’t been released yet, and we are still working and actively merging remaining fixes and improvements before rolling out a proper Beta/GA release.
That said, we’re definitely looking into this specific commit to ensure it’s fully addressed before launch.
Thanks again for helping us make the upcoming release solid and secure!
Good to see this being documented publicly. Even with authentication required, allowing a regular UCP user to modify another user’s contacts is something administrators would probably want to know about. The Green urgency rating makes sense if the issue requires an authenticated account, but it’s still worth checking whether the affected versions need an update or patch.