Latest News
In the early morning hours of March 10, thousands of users on X (formerly Twitter) began having trouble logging into the...
## Summary `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. ## Details The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. ## Impact By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. ## Mitigation - Update to the latest version of Rack, or - Remove usage of `Rack::Static`, or - Ensure that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.
International law enforcement disrupts Garantex, a multi-billion-dollar cryptocurrency exchange used for money laundering. Two individuals, Aleksej Besciokov and…
The telecom industry is at a major turning point. With 5G, IoT, and AI reshaping global connectivity, the…
Concrete CMS versions 9.0.0 through 9.3.9 are affected by a stored XSS in Folder Function.The "Add Folder" functionality lacks input sanitization, allowing a rogue admin to inject XSS payloads as folder names. The Concrete CMS security team gave this vulnerability a CVSS 4.0 Score of 4.8 with vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N. Versions below 9 are not affected. Thanks, Alfin Joseph for reporting.
This vulnerability is caused by the improper mapping of users to organizations based solely on email/username patterns. The issue is limited to the token claim level, meaning the user is not truly added to the organization but may appear as such in applications relying on these claims. The risk increases in scenarios where self-registration is enabled and unrestricted, allowing an attacker to exploit the naming pattern. The issue is mitigated if admins restrict registration or use strict validation mechanisms.
The issue arises because Keycloak does not perform an LDAP bind after a password reset, leading to potential authentication bypass for expired or disabled AD accounts. A fix should enforce LDAP validation after password updates to ensure consistency with AD authentication policies.
Should a VM specialist be aware of what is happening in the Darknet? Of course. At least roughly. Otherwise, he’ll fall for the “nobody’s attacking us” myth. 😏 The reality is that every organization is under attack all the time. It’s like commercial fishing with trawlers. Anything that gets caught in the nets will be […]
### Impact Due to lack of limits by default in the [`explode()`](https://www.php.net/manual/en/function.explode.php) function, malicious clients were able to abuse some packets to waste server CPU and memory. This is similar to a previous security issue published in https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-gj94-v4p9-w672, but with a wider impact, including but not limited to: - Sign editing - LoginPacket JWT parsing - Command parsing However, the estimated impact of these issues is low, due to other limits such as the packet decompression limit. ### Patches The issue was fixed in 5.25.2 via d0d84d4c5195fb0a68ea7725424fda63b85cd831. A custom PHPStan rule has also been introduced to the project, which will henceforth require that all calls to `explode()` within the codebase must specify the `limit` parameter. ### Workarounds No simple way to fix this. Given that sign editing is the easiest way this could be exploited, workarounds could include plugins pre-proc...
### Summary Stored Cross-Site Scripting (XSS) vulnerability allows attackers to inject malicious scripts into web applications, which can then be executed in the context of other users' browsers. This can lead to unauthorized access to sensitive information, session hijacking, and spreading of malware, impacting user data privacy and application integrity. ### Details A user with rights to modificate the service (e.g. kuiperUser role) can inject XSS Payload into Rule `id` parameter. Then, after any user with access to this service (e.g. admin) will try make any modifications with the rule (update, run, stop, delete), a payload will act in victim's browser. The issue appears as the notification to user is made in an insafe way: https://github.com/lf-edge/ekuiper/blob/dbce32d5a195cf1de949b3a6a4e29f0df0f3330d/internal/server/rest.go#L681 https://github.com/lf-edge/ekuiper/blob/dbce32d5a195cf1de949b3a6a4e29f0df0f3330d/internal/server/rest.go#L716 https://github.com/lf-edge/ekuiper/bl...