Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2023-1862 |
Description: Cloudflare WARP client for Windows (up to v2023.3.381.0) allowed a malicious actor to remotely access the warp-svc.exe binary due to an insufficient access control policy on an IPC Named Pipe. This would have enabled an attacker to trigger WARP connect and disconnect commands, as well as obtaining network diagnostics and application configuration from the target's device. It is important to note that in order to exploit this, a set of requirements would need to be met, such as the target's device must've been reachable on port 445, allowed authentication with NULL sessions or otherwise having knowledge of the target's credentials.
CVSS: HIGH (7.3) EPSS Score: 0.07%
December 10th, 2024 (4 months ago)
|
|
Description: Summary
If a server.ca file is present in LXD_DIR at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD.
We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store.
- The LXD Go client (and by extension lxc) does not send non-CA signed certificates during the handshake.
- A manual client (e.g. cURL) might send a non-CA signed certificate during the handshake.
Versions affected
LXD 4.0 and above.
Details
When PKI mode was added to LXD it was intended that all client and server certificates must be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909).
In PKI mode, the TLS listener configuration is altered to add the CA certificate but the ClientAuth field of tls.Config is not changed. The ClientAuth field is set to tls.RequestClientCert, which configures the TLS connection to request a certificate from the client, but not require one. This is necessary because untrusted requests are allowed for some endpoints.
If a client certificate is present in the trust store before PKI mode is enabled, calls to LXD using that certificate fail when using the Go client for LXD. I believe that what is happening is as follows:
During the TLS handshake, the server requests a cer...
December 10th, 2024 (4 months ago)
|
|
|
Description: Summary
If a server.ca file is present in LXD_DIR at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA.
The LXD configuration option core.trust_ca_certificates defaults to false. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS.
When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD.
Details
When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the core.trust_ca_certificates configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. This cherry-pick from Incus was added to LXD to fix the issue.
The cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when core.trust_ca_certificates is enabled, but did not consider the behaviour of LXD when core.trust_ca_certificates is disabled.
When core.trust_ca_certificates is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a server.ca file in LXD_DIR.
PoC
# Install/initialize LXD
$ snap install lxd --channel 5.21/stable
$ lxd init --auto
$ lxc config set core.h...
December 9th, 2024 (4 months ago)
|
|
|
Description: unstructured v.0.14.2 and before is vulnerable to XML External Entity (XXE) via the XMLParser.
References
https://nvd.nist.gov/vuln/detail/CVE-2024-46455
https://binarysouljour.me/cve-2024-46455
https://github.com/Unstructured-IO/unstructured/pull/3088
https://github.com/Unstructured-IO/unstructured/commit/171b5df09fc3346aba8ce91c04de5b3e094a86bd
https://github.com/advisories/GHSA-32r8-54hf-c9p3
December 9th, 2024 (4 months ago)
|
|
|
Description: Artivion, a leading manufacturer of heart surgery medical devices, has disclosed a November 21 ransomware attack that disrupted some of its operations and forced it to take some systems offline. [...]
December 9th, 2024 (4 months ago)
|
|
|
Description: The second zero-day vulnerability found in Windows NTLM in the past two months paves the way for relay attacks and credential theft. Microsoft has no patch, but released updated NTLM cyberattack mitigation advice.
December 9th, 2024 (4 months ago)
|
|
|
Description: A flaw in OpenWrt's Attended Sysupgrade feature used to build custom, on-demand firmware images could have allowed for the distribution of malicious firmware packages. [...]
December 9th, 2024 (4 months ago)
|
|
|
Description: Scammers set up call centers in luxury rentals to run bank help-desk fraud, as well as large-scale phishing campaigns, across at least 10 European countries, according to law enforcement.
December 9th, 2024 (4 months ago)
|
|
|
Description: Impact
Affected versions of Winter CMS allow users with access to the CMS templates sections that modify Twig files to bypass the sandbox placed on Twig files and modify resources such as theme customisation values or modify, or remove, templates in the theme even if not provided direct access via the permissions.
As all objects passed through to Twig are references to the live objects, it is also possible to also manipulate model data if models are passed directly to Twig, including changing attributes or even removing records entirely. In most cases, this is unwanted behavior and potentially dangerous.
To actively exploit this security issue, an attacker would need access to the Backend with a user account with any of the following permissions:
cms.manage_layouts
cms.manage_pages
cms.manage_partials
The Winter CMS maintainers strongly recommend that these permissions only be reserved to trusted administrators and developers in general.
Patches
In order to mitigate this issue, we have significantly increased the scope of the sandbox, effectively making all models and datasources read-only in Twig.
This security issue has been fixed as of https://github.com/wintercms/winter/commit/fb88e6fabde3b3278ce1844e581c87dcf7daee22.
Workarounds
If you cannot upgrade, you may apply commit https://github.com/wintercms/winter/commit/fb88e6fabde3b3278ce1844e581c87dcf7daee22 to your Winter CMS installation manually to resolve this issue.
In the rare event that you were relying on being ...
December 9th, 2024 (4 months ago)
|
|
|
Description: Impact
Several polynomial time complexity issues in league/commonmark may lead to unbounded resource exhaustion and subsequent denial of service.
Malicious users could trigger that inefficient code with carefully crafted Markdown inputs that are specifically designed to ensure the worst-case performance is reached. Sending multiple such requests in parallel could tie up all available CPU resources and/or PHP-FPM processes, leading to denial of service for legitimate users.
Patches
These vulnerabilities have been patched in version 2.6.0. All users on older versions are highly encouraged to upgrade as soon as possible.
Workarounds
If you cannot upgrade, you may be able to mitigate the issues by:
Setting very low memory_limit and max_execution_time PHP configurations to prevent runaway resource usage
Implementing rate-limiting, bot protection, or other approaches to reduce the risk of simultaneous bad requests hitting your site
Limiting the size of inputs fed into this library (specifically the max length of each line)
Limiting the use of this library to trusted users
References
Most of these issues were discovered in other Markdown parsers. You can read more about them here:
https://github.com/commonmark/commonmark.js/issues/129
https://github.com/commonmark/commonmark.js/issues/157
https://github.com/commonmark/commonmark.js/issues/172
https://github.com/github/cmark-gfm/security/advisories/GHSA-r572-jvj2-3m8p
https://github.com/github/cmark-gfm/security/advisories/GH...
December 9th, 2024 (4 months ago)
|