Most recent entries from pysec

pysec-2026-1339

Tue, 07 Jul 2026 14:34:36 +0000

### Note On Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure `polyfill.io` and its subdomains could not resolve to the compromised service, rendering this vulnerability **unexploitable**. The following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable. ### Impact `fides.js`, a client-side script used to interact with the consent management features of Fides, used the `polyfill.io` domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard. On June 25th, 2024, Sansec published the following regarding the `polyfill.io` domain. > The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain... However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io. Therefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving `fides.js` to download and execute malicious scripts from the compromised domain. No exploitation of `fides.js` via `polyfill.io` has been identified at this time, but other script developers who use `https://cdn.polyfill.io/v2/polyfill.min.js` have reported redirects to malicious websites. ### Patches The vulnerability has been patched in Fides version `2.39.1`. Users are advised to upgrade to this version or later to secure their systems against this threat. ### Workarounds Prior to the domain level intervention, there were no server-side workarounds and the confidentiality, integrity, and availability impacts of this vulnerability were high. Clients could ensure they were not affected by using a modern browser that supported the fetch standard. caniuse.com/fetch estimates that 97.52% of browser users use a browser that supports the fetch standard. ### References - https://sansec.io/research/polyfill-supply-chain-attack - https://github.com/ethyca/fides/pull/5026/ - https://fetch.spec.whatwg.org/

pysec-2026-1497

Tue, 07 Jul 2026 11:45:18 +0000

### Impact In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration. ### Patches With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account! ### Workarounds No workaround exists. ### References Disclosed by [@novemberdad](https://huntr.dev/bounties/1714df73-e639-4d64-ab25-ced82dad9f85/).

pysec-2026-1924

Tue, 07 Jul 2026 16:03:20 +0000

### Summary The sigstore-python OAuth authentication flow is susceptible to Cross-Site Request Forgery. ### Details `_OAuthSession` creates a unique "state" and sends it as a parameter in the authentication request but the "state" in the server response seems not not be cross-checked with this value. Fix should be fairly trivial. ### Impact This should be low impact: A man-in-the middle attacker could trick a sigstore-python user into signing something with an identity controlled by the attacker (by returning the response to an authentication request they created). This would be quite confusing but not dangerous.

pysec-2026-2042

Tue, 07 Jul 2026 16:03:12 +0000

### Impact It was possible to accept an invitation opened by a different Weblate user. ### Patches * https://github.com/WeblateOrg/weblate/pull/16913 ### Workarounds Users should avoid leaving Weblate sessions with an unattended opened invitation. ### References Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.

pysec-2026-195

Thu, 04 Jun 2026 12:16:24 +0000

A flaw has been found in MLflow up to 3.10.0. This issue affects the function mlflow.data.digest_utils of the file mlflow/data/digest_utils.py of the component Dataset Digest Computation. This manipulation causes use of weak hash. It is possible to launch the attack on the local host. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through a pull request but has not reacted yet.

pysec-2026-1672

Tue, 07 Jul 2026 16:03:03 +0000

### Summary The GET /download/ route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak. ### Details ``` def is_safe_path(safe_root, check_path): safe_root = os.path.realpath(os.path.normpath(safe_root)) check_path = os.path.realpath(os.path.normpath(check_path)) return os.path.commonprefix([check_path, safe_root]) == safe_root ``` commonprefix compares raw strings, not path components. For: ``` safe_root = /home/mobsf/.MobSF/downloads check_path = /home/mobsf/.MobSF/downloads_bak/test.txt ``` the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler: ``` # MobSF/views/home.py @login_required def download(request): root = settings.DWD_DIR filename = request.path.replace('/download/', '', 1) dwd_file = Path(root) / filename # absolute 'filename' ignores 'root' if '../' in filename or not is_safe_path(root, dwd_file): return HttpResponseForbidden(...) ext = dwd_file.suffix if ext in settings.ALLOWED_EXTENSIONS and dwd_file.is_file(): return file_download(dwd_file, ...) ``` If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed is_safe_path then accepts any sibling directory whose absolute path shares the same string prefix. The ../ check does not catch this. Which file types are retrievable: Whatever is allowed by settings.ALLOWED_EXTENSIONS ### PoC Prereqs: authenticated user; standard install. Assume: ``` settings.DWD_DIR = /home/mobsf/.MobSF/downloads ``` Prepare a sibling directory with the same string prefix and a test file: ``` mkdir -p /home/mobsf/.MobSF/downloads_bak echo "test" > /home/mobsf/.MobSF/downloads_bak/test.txt ``` As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it): ``` GET /download///home/mobsf/.MobSF/downloads_bak/test.txt HTTP/1.1 Host: Cookie: sessionid= ``` Other working sibling directory names (if present): ``` …/downloads.old/... …/downloads_backup/... …/downloads1/... …/downloads-archive/... …/downloads 2024/... (URL-encoded space: downloads%202024) ``` ### Impact Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWD_DIR.

pysec-2026-1104

Tue, 07 Jul 2026 16:02:58 +0000

### Summary The Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. ### Impact If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. ---- Patch: https://github.com/aio-libs/aiohttp/commit/e8d774f635dc6d1cd3174d0e38891da5de0e2b6a

pysec-2026-1354

Tue, 07 Jul 2026 16:03:02 +0000

### Impact An out-of-bounds read was found in Exiv2 versions v0.28.5 and earlier. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The out-of-bounds read is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to cause a denial of service by crashing Exiv2, if they can trick the victim into running Exiv2 on a crafted image file. Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. For example, to trigger the bug in the Exiv2 command-line application, you need to add an extra command-line argument such as delete. ### Patches The bug is fixed in version v0.28.6. ### Credit Thank you to @dragonArthurX for reporting this issue. ### Details (from original report by @dragonArthurX ) **Version:** Tested on v0.28.5 (latest official release) Commit: 907169fa643c2c74c14fd4106e55eaeee3634d9f **Platform:** Ubuntu 20.04.6 LTS (x86_64) **Build Steps:** ```bash git clone https://github.com/Exiv2/exiv2.git cd exiv2 git checkout v0.28.5 mkdir build-v0.28.5 && cd build-v0.28.5 cmake -DCMAKE_C_COMPILER=/fuzzer/afl-clang-fast -DCMAKE_CXX_COMPILER=/fuzzer/afl-clang-fast++ -DCMAKE_C_FLAGS="-g -fsanitize=address" -DCMAKE_CXX_FLAGS="-g -fsanitize=address" -DBUILD_SHARED_LIBS=OFF ../ ``` **Command line to reproduce:** ```bash /home/exiv2/build/bin/exiv2 -d a -f /home/poc ``` **Crash Output:** ``` AddressSanitizer:DEADLYSIGNAL ================================================================ = ==376531==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd92236b0e7 (pc 0x7fd82314dcd2 bp 0x7ffd540ceba0 sp 0x7ffd540ce358 T0) ==376531==The signal is caused by a READ memory access. #0 0x7fd82314dcd2 /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383 #1 0x4ed131 in __asan_memcpy (/home/exiv2/build-v0.28.5/bin/exiv2+0x4ed131) #2 0x6184b1 in Exiv2::MemIo::write(unsigned char const*, unsigned long) /home/exiv2/src/basicio.cpp:704:5 #3 0xad336d in (anonymous namespace)::writeTemp(Exiv2::BasicIo&, unsigned char const*, unsigned long) /home/exiv2/src/epsimage.cpp:90:14 #4 0xac3a07 in (anonymous namespace)::readWriteEpsMetadata(Exiv2::BasicIo&, std::__cxx11::basic_string, std::allocator >&, std::vector >&, bool) /home/exiv2/src/epsimage.cpp:1009:7 #5 0xad1175 in Exiv2::EpsImage::writeMetadata() /home/exiv2/src/epsimage.cpp:1103:3 #6 0x5d2383 in Action::Erase::run(std::__cxx11::basic_string, std::allocator > const&) /home/exiv2/app/actions.cpp:713:14 #7 0x522d02 in main /home/exiv2/app/exiv2.cpp:177:25 #8 0x7fd8230b6082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16 #9 0x4714dd in _start (/home/exiv2/build-v0.28.5/bin/exiv2+0x4714dd) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383 ==376531==ABORTING ```

pysec-2026-1355

Tue, 07 Jul 2026 16:03:02 +0000

### Impact A denial-of-service was found in Exiv2 version v0.28.5: a quadratic algorithm in the ICC profile parsing code in `jpegBase::readMetadata()` can cause Exiv2 to run for a long time. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted jpg image file. ### Patches The bug is fixed in version v0.28.6. ### References Issue: https://github.com/Exiv2/exiv2/issues/3333 Fixes: https://github.com/Exiv2/exiv2/pull/3335 (main branch), https://github.com/Exiv2/exiv2/pull/3345 (0.28.x branch) ### For more information Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.

pysec-2026-1377

Tue, 07 Jul 2026 16:02:52 +0000

In Flask 3.1.0, the way fallback key configuration was handled resulted in the last fallback key being used for signing, rather than the current signing key. Signing is provided by the `itsdangerous` library. A list of keys can be passed, and it expects the last (top) key in the list to be the most recent key, and uses that for signing. Flask was incorrectly constructing that list in reverse, passing the signing key first. Sites that have opted-in to use key rotation by setting `SECRET_KEY_FALLBACKS` are likely to unexpectedly be signing their sessions with stale keys, and their transition to fresher keys will be impeded. Sessions are still signed, so this would not cause any sort of data integrity loss.