CVE-2025-1390Medium· 6.1▾ SunlitThe PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being g…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 33.6 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Oct 15.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.2%
0.2% → 0.2%
The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-4878Medium· 6.7A flaw was found in libcap
CVE-2019-13565High· 7.5An issue was discovered in OpenLDAP 2.x before 2.4.48
CVE-2013-10077Medium· 5.3OctoPrint API Key settings.py getSettings information disclosure
CVE-2025-10070Medium· 6.3Portabilis i-Educar enturmacao-em-lote access control
CVE-2025-10071Medium· 6.3Portabilis i-Educar cancelar-enturmacao-em-lote access control
CVE-2016-5388High· 8.1Apache Tomcat 7.x through 7.0.70 and 8.x through 8.5.4, when the CGI Servlet is enabled, follows RFC 3875 section 4.1.18 and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment…