CVE-2007-2249 : Detail

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

Date	EPSS V0	EPSS V1	EPSS V2 (> 2022-02-04)	EPSS V3 (> 2025-03-07)	EPSS V4 (> 2025-03-17)
2022-02-06	–	–	9.66%	–	–
2022-04-03	–	–	9.66%	–	–
2023-03-12	–	–	–	3.2%	–
2023-12-17	–	–	–	3.13%	–
2024-01-21	–	–	–	3.04%	–
2024-02-11	–	–	–	3.04%	–
2024-06-02	–	–	–	3.04%	–
2024-08-04	–	–	–	2.55%	–
2024-11-10	–	–	–	2.55%	–
2024-12-22	–	–	–	1.99%	–
2024-12-29	–	–	–	1.99%	–
2025-01-05	–	–	–	1.99%	–
2025-01-19	–	–	–	1.99%	–
2025-03-18	–	–	–	–	13.05%
2025-03-30	–	–	–	–	13.05%
2025-04-06	–	–	–	–	15.93%
2025-04-06	–	–	–	–	15.93,%

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.

Date	Percentile
2022-02-06	87%
2022-04-03	94%
2023-03-12	9%
2023-12-17	9%
2024-01-21	9%
2024-02-11	91%
2024-06-02	91%
2024-08-04	9%
2024-11-10	91%
2024-12-22	89%
2024-12-29	88%
2025-01-05	89%
2025-01-19	89%
2025-03-18	94%
2025-03-30	93%
2025-04-06	94%
2025-04-06	94%

source: https://www.securityfocus.com/bid/23616/info Phorum is prone to multiple input-validation vulnerabilities, including an unauthorized-access issue, privilege-escalation issue, multiple SQL-injection issues, and cross-site scripting issues, because the application fails to sufficiently sanitize user-supplied input. Exploiting these issues could allow an attacker to steal cookie-based authentication credentials, compromise the application, access or modify sensitive data, or exploit latent vulnerabilities in the underlying database implementation. Phorum 5.1.20 is affected; prior versions may also be vulnerable. All parameters must be set correctly for this exploit to work. "/control.php?1" --> "1" is forum id, where moderator has user moderation privileges. "user_ids[2]" --> "2" is userid of the user, who want's to get admin privileges And of course, moderator must be logged in before using exploit. It's that easy - you push the button - and you have admi rights!! So where is the initial problem for this security hole? Let's look at sourrce code of "include/controlcenter/users.php" line 29: ------------------[source code]---------------------- if(!empty($_POST["user_ids"])){ foreach($_POST["user_ids"] as $user_id){ if(!isset($_POST["approve"])){ $userdata["active"]=PHORUM_USER_INACTIVE; } else { $user=phorum_user_get($user_id); if($user["active"]==PHORUM_USER_PENDING_BOTH){ $userdata["active"]=PHORUM_USER_PENDING_EMAIL; } else { $userdata["active"]=PHORUM_USER_ACTIVE; // send reg approved message $maildata["mailsubject"]=$PHORUM["DATA"]["LANG"]["RegApprovedSubject"]; $maildata["mailmessage"]=wordwrap($PHORUM["DATA"]["LANG"]["RegApprovedEmailBody"], 72); phorum_email_user(array($user["email"]), $maildata); } } $userdata["user_id"]=$user_id; phorum_user_save($userdata); } } ------------------[/source code]---------------------- As we can see, by manipulating $_POST["user_ids"] parameter any user can be activated or deactivated. Including admin. So - there is no checking, if target user is allready active or has it higher privileges than moderator. This was mistake one. Now, mistake number two. Array "$userdata" is uninitialized. So we can "poison" that variable, if php settings has "register_globals=on". And in this way user moderator can deliver for saving any userdata for any user. For example - userdata[admin] carries user admin privileges. Solution: array initializing before use and adding some security checks.