python, the official language of "well i could just use python"
Colossal blunder on my part this afternoon.
Pulled the drives from an areca raid array and
forgot what order they have to go back in
so now the array isn't recognized and RESCUE doesn't see it.
Has anyone documented the magic parameter sectors that describe this anywhere?
Really big scoop (I don't think @briankrebs knows how big yet) here - he's tracked down somebody who says they are Rey from Lapsus$.
I don't wanna say why yet as I don't have all the pieces of the jigsaw, but I imagine this is going to turn into a long thread over time.
https://krebsonsecurity.com/2025/11/meet-rey-the-admin-of-scattered-lapsus-hunters/
well strlen() returns the amount of bytes so in this regard multibyte characters are not really an issue per see.
https://gitlab.gnome.org/GNOME/glib/-/blob/f28340ee62c655487972ad3c632d231ee098fb7f/glib/gconvert.c#L1318 defines a char array of acceptable (meaning ASCII) characters.
Then it iterates over the dynamically allocated buffer and keeps track of the amount of "unacceptable" characters.
unacceptable was a gint (https://docs.gtk.org/glib/types.html#gint) which could therefore overflow.
To me it does look like glib could use some refactoring.
https://gitlab.gnome.org/GNOME/glib/-/commit/f28340ee62c655487972ad3c632d231ee098fb7f
Neat vuln in Fail2Ban.
https://gist.github.com/R-Security/1c707a08f9c7f9a91d9d84b5010aaed2
Fail2Ban 0.11.2 contains a vulnerability that allows an attacker with the ability to influence logged input (e.g., authentication logs, service logs processed by Fail2Ban filters) to inject specially crafted patterns that lead to command execution within the Fail2Ban action processing pipeline.
Because Fail2Ban actions typically run with root privileges, this can result in privilege escalation, allowing an attacker to execute commands with elevated permissions.
The issue arises from insufficient sanitization of variables passed into action scripts under certain configurations, allowing malicious input to propagate into shell execution.
That's an avenue that I admit I hadn't thought to check before. Seems so simple though.
https://access.redhat.com/security/cve/CVE-2025-13601
A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.