| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When installing Nessus to a non-default location on a Windows host, Nessus versions prior to 10.8.4 did not enforce secure permissions for sub-directories. This could allow for local privilege escalation if users had not secured the directories in the non-default installation location. - CVE-2025-24914 |
| When installing Nessus Agent to a non-default location on a Windows host, Nessus Agent versions prior to 10.8.3 did not enforce secure permissions for sub-directories. This could allow for local privilege escalation if users had not secured the directories in the non-default installation location. |
| In libexpat in Expat before 2.2.7, XML input including XML names that contain a large number of colons could make the XML parser consume a high amount of RAM and CPU resources while processing (enough to be usable for denial-of-service attacks). |
| Insufficiently Protected Credentials: An authenticated user with debug privileges can retrieve stored Nessus policy credentials from the “nessusd” process in cleartext via process dumping. The affected products are all versions of Nessus Essentials and Professional. The vulnerability allows an attacker to access credentials stored in Nessus scanners, potentially compromising its customers’ network of assets. |
| An authenticated attacker could read Nessus Debug Log file attachments from the web UI without having the correct privileges to do so. This may lead to the disclosure of information on the scan target and/or the Nessus scan to unauthorized parties able to reach the Nessus instance. |
| Expat (aka libexpat) before 2.4.4 has an integer overflow in the doProlog function. |
| Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES. |
| storeAtts in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| nextScaffoldPart in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| lookup in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| defineAttribute in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| build_model in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| addBinding in xmlparse.c in Expat (aka libexpat) before 2.4.3 has an integer overflow. |
| In doProlog in xmlparse.c in Expat (aka libexpat) before 2.4.3, an integer overflow exists for m_groupSize. |
| In Expat (aka libexpat) before 2.4.3, a left shift by 29 (or more) places in the storeAtts function in xmlparse.c can lead to realloc misbehavior (e.g., allocating too few bytes, or only freeing memory). |
| An authenticated attacker could utilize the identical agent and cluster node linking keys to potentially allow for a scenario where unauthorized disclosure of agent logs and data is present. |
|
A command injection vulnerability exists where an authenticated, remote attacker with administrator privileges on the Security Center application could modify Logging parameters, which could lead to the execution of arbitrary code on the Security Center host.
|
| A crafted method sent through HTTP/2 will bypass validation and be forwarded by mod_proxy, which can lead to request splitting or cache poisoning. This issue affects Apache HTTP Server 2.4.17 to 2.4.48. |
| A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser (r:parsebody() called from Lua scripts). The Apache httpd team is not aware of an exploit for the vulnerabilty though it might be possible to craft one. This issue affects Apache HTTP Server 2.4.51 and earlier. |
| Composer is a dependency manager for the PHP programming language. Integrators using Composer code to call `VcsDriver::getFileContent` can have a code injection vulnerability if the user can control the `$file` or `$identifier` argument. This leads to a vulnerability on packagist.org for example where the composer.json's `readme` field can be used as a vector for injecting parameters into hg/Mercurial via the `$file` argument, or git via the `$identifier` argument if you allow arbitrary data there (Packagist does not, but maybe other integrators do). Composer itself should not be affected by the vulnerability as it does not call `getFileContent` with arbitrary data into `$file`/`$identifier`. To the best of our knowledge this was not abused, and the vulnerability has been patched on packagist.org and Private Packagist within a day of the vulnerability report. |
