Latest News
**What is the version information for this release?** Microsoft Edge Version Date Released Based on Chromium Version 131.0.2903.63 11/21/2024 131.0.6778.85/.86
Google has revealed that its AI-powered fuzzing tool, OSS-Fuzz, has been used to help identify 26 vulnerabilities in various open-source code repositories, including a medium-severity flaw in the OpenSSL cryptographic library. "These particular vulnerabilities represent a milestone for automated vulnerability finding: each was found with AI, using AI-generated and enhanced fuzz targets,"
Threat hunters are warning about an updated version of the Python-based NodeStealer that's now equipped to extract more information from victims' Facebook Ads Manager accounts and harvest credit card data stored in web browsers. "They collect budget details of Facebook Ads Manager accounts of their victims, which might be a gateway for Facebook malvertisement," Netskope Threat Labs researcher
### Impact First noticed in Opencast 13 and 14, Opencast's Elasticsearch integration may generate syntactically invalid Elasticsearch queries in relation to previously acceptable search queries. From Opencast version 11.4 and newer, Elasticsearch queries are retried a configurable number of times in the case of error to handle temporary losses of connection to Elasticsearch. These invalid queries would fail, causing the retry mechanism to begin requerying with the same syntactically invalid query immediately, in an infinite loop. This causes a massive increase in log size which can in some cases cause a denial of service due to disk exhaustion. ### Patches Opencast 13.10 and Opencast 14.3 contain patches (https://github.com/opencast/opencast/pull/5150, and https://github.com/opencast/opencast/pull/5033) which address the base issue, with Opencast 16.7 containing changes which harmonize the search behaviour between the admin UI and external API. Users are strongly recommended to up...
November Linux Patch Wednesday. I was happy in October that the number of vulnerabilities was gradually decreasing to an acceptable level, and in November I got a peak again. A total of 803 vulnerabilities. Of these, 567 are in the Linux Kernel. Kind of crazy. 😱 2 vulnerabilities in Chromium with signs of exploitation in […]
### Summary Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests. ### Details The `Request` methods to parse json, msgpack or form-data all read the entire request stream into memory via `await self.body()` without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen. For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via `multipart/form-data`, a simple size limit would not be practical. T...
Querydsl 5.1.0 allows SQL/HQL injection in orderBy in JPAQuery.
Efficiency is the name of the game for the security operations center — and 91% of cybersecurity pros say artificial intelligence and machine learning are winning that game.
Palo Alto, California, 20th November 2024, CyberNewsWire
### Impact cert-manager packages which call the standard library `pem.Decode()` function can take a long time to process specially crafted invalid PEM data. If an attacker is able to modify PEM data which cert-manager reads (e.g. in a Secret resource), they may be able to use large amounts of CPU in the cert-manager controller pod to effectively create a denial-of-service (DoS) vector for cert-manager in the cluster. Secrets are limited in size to [1MiB](https://kubernetes.io/docs/concepts/configuration/secret/#restriction-data-size), which reduces the impact of this issue; it was discovered through an ~856kB fuzz test input which causes `pem.Decode` to take roughly 750ms to reject the input on an M2 Max Macbook Pro. By way of comparison, a valid PEM-encoded 4096-bit RSA key takes roughly 70µs to parse on the same machine. Given the required size of PEM data needed to present a realistic DoS vector, an attacker would need to create or insert many different large sized resources in...