Vulnerabilidades de Linuxfoundation

Backstage is an open framework for building developer portals, and @backstage/plugin-techdocs-node provides common node.js functionalities for TechDocs. In versions of @backstage/plugin-techdocs-node prior to 1.13.11 and 1.14.1, when TechDocs is configured with `runIn: local`, a malicious actor who can submit or modify a repository's `mkdocs.yml` file can execute arbitrary Python code on the TechDocs build server via MkDocs hooks configuration. @backstage/plugin-techdocs-node versions 1.13.11 and 1.14.1 contain a fix. The fix introduces an allowlist of supported MkDocs configuration keys. Unsupported configuration keys (including `hooks`) are now removed from `mkdocs.yml` before running the generator, with a warning logged to indicate which keys were removed. Users of `@techdocs/cli` should also upgrade to the latest version, which includes the fixed `@backstage/plugin-techdocs-node` dependency. Some workarounds are available. Configure TechDocs with `runIn: docker` instead of `runIn: local` to provide container isolation, though it does not fully mitigate the risk. Limit who can modify `mkdocs.yml` files in repositories that TechDocs processes; only allow trusted contributors. Implement PR review requirements for changes to `mkdocs.yml` files to detect malicious `hooks` configurations before they are merged. Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features. Building documentation in CI/CD pipelines using `@techdocs/cli` does not mitigate this vulnerability, as the CLI uses the same vulnerable `@backstage/plugin-techdocs-node` package.

Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. The `ig` binary provides a subcommand for image building, used to generate custom gadget OCI images. A part of this functionality is implemented in the file `inspektor-gadget/cmd/common/image/build.go`. The `Makefile.build` file is the Makefile template employed during the building process. This file includes user-controlled data in an unsafe fashion, specifically some parameters are embedded without an adequate escaping in the commands inside the Makefile. Prior to version 0.48.1, this implementation is vulnerable to command injection: an attacker able to control values in the `buildOptions` structure would be able to execute arbitrary commands during the building process. An attacker able to exploit this vulnerability would be able to execute arbitrary command on the Linux host where the `ig` command is launched, if images are built with the `--local` flag or on the build container invoked by `ig`, if the `--local` flag is not provided. The `buildOptions` structure is extracted from the YAML gadget manifest passed to the `ig image build` command. Therefore, the attacker would need a way to control either the full `build.yml` file passed to the `ig image build` command, or one of its options. Typically, this could happen in a CI/CD scenario that builds untrusted gadgets to verify correctness. Version 0.51.1 fixes the issue.

Podman Desktop is a graphical tool for developing on containers and Kubernetes. A critical authentication bypass vulnerability in Podman Desktop prior to version 1.25.1 allows any extension to completely circumvent permission checks and gain unauthorized access to all authentication sessions. The `isAccessAllowed()` function unconditionally returns `true`, enabling malicious extensions to impersonate any user, hijack authentication sessions, and access sensitive resources without authorization. This vulnerability affects all versions of Podman Desktop. Version 1.25.1 contains a patch for the issue.

PyTorch is a Python package that provides tensor computation. Prior to version 2.10.0, a vulnerability in PyTorch's `weights_only` unpickler allows an attacker to craft a malicious checkpoint file (`.pth`) that, when loaded with `torch.load(..., weights_only=True)`, can corrupt memory and potentially lead to arbitrary code execution. Version 2.10.0 fixes the issue.

EVerest is an EV charging software stack. Prior to version 2025.10.0, during the deserialization of a `DC_ChargeLoopRes` message that includes Receipt as well as TaxCosts, the vector `<DetailedTax>tax_costs` in the target `Receipt` structure is accessed out of bounds. This occurs in the method `template <> void convert(const struct iso20_dc_DetailedTaxType& in, datatypes::DetailedTax& out)` which leads to a null pointer dereference and causes the module to terminate. The EVerest processes and all its modules shut down, affecting all EVSE. Version 2025.10.0 fixes the issue.

EVerest is an EV charging software stack. Prior to version 2025.10.0, an integer overflow occurring in `SdpPacket::parse_header()` allows the current buffer length to be set to 7 after a complete header of size 8 has been read. The remaining length to read is computed using the current length subtracted by the header length which results in a negative value. This value is then interpreted as `SIZE_MAX` (or slightly less) because the expected type of the argument is `size_t`. Depending on whether the server is plain TCP or TLS, this leads to either an infinite loop or a stack buffer overflow. Version 2025.10.0 fixes the issue.

EVerest is an EV charging software stack. Prior to version 2025.10.0, once the module receives a SDP request, it creates a whole new set of objects like `Session`, `IConnection` which open new TCP socket for the ISO15118-20 communications and registers callbacks for the created file descriptor, without closing and destroying the previous ones. Previous `Session` is not saved and the usage of an `unique_ptr` is lost, destroying connection data. Latter, if the used socket and therefore file descriptor is not the last one, it will lead to a null pointer dereference. Version 2025.10.0 fixes the issue.

EVerest is an EV charging software stack. Prior to version 2025.10.0, the use of the `assert` function to handle errors frequently causes the module to crash. This is particularly critical because the manager shuts down all other modules and exits when any one of them terminates, leading to a denial of service. In a context where a manager handles multiple EVSE, this would also impact other users. Version 2025.10.0 fixes the issue.

EVerest is an EV charging software stack. In versions 2025.9.0 and below, an attacker can exhaust the operating system's memory and cause the module to terminate by initiating an unlimited number of TCP connections that never proceed to ISO 15118-2 communication. This is possible because a new thread is started for each incoming plain TCP or TLS socket connection before any verification occurs, and the verification performed is too permissive. The EVerest processes and all its modules shut down, affecting all EVSE functionality. This issue is fixed in version 2025.10.0.