aiosmtplib is an asynchronous SMTP client for use with asyncio. Prior to 5.1.2, SMTPProtocol.start_tls in src/aiosmtplib/protocol.py consumes the server's 220 response and starts the TLS handshake without clearing SMTPProtocol._buffer. An active network attacker can place attacker-chosen SMTP response lines after the plaintext 220 response in the same network segment. The method then calls loop.start_tls; those bytes survive the transport upgrade and are parsed as the first response from inside the TLS session, desynchronizing subsequent SMTP command and response pairs. Connections using start_tls=True or opportunistic STARTTLS are affected,
GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)
GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.
### Impact
- **Private record metadata disclosure.** Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record's contact details (PII), keywords, and distributions. (Runtime-proven.)
- **Private tile data via shared caches.** Private raster and vector tiles were served with shared-cache (`Cache-Control: public`) headers, so a shared cache (a CDN or the bun
tarfile extraction filter bypass allows creation of directories outside the destination
The tarfile module's tar and data
extraction filters created directories outside the destination for
members whose name leaves the destination and returns to it, such as ../evil/../dest/sub/file. The containment check used the resolved path, but intermediate directories were created from the name as given.
Only
empty directories are created outside the destination. Member contents
are still extracted inside it. To return to the destination the member's
name must contain the destination directory's own final component, so
extraction into a secure randomised directory is not affected.
This affects POSIX platforms only. On Windows, .. co
stigmem (pip package stigmem-node) version 0.9.0a1 contains a timestamp-handling mismatch in federation peer-token validation that can cause valid peer tokens to be incorrectly treated as expired. This affects the availability and reliability of authenticated federation flows on nodes using federation peer authentication paths. The issue is fixed in 0.9.0a2, which uses the canonical millisecond-based validation path.
stigmem-node Insecure Federation Transport Configuration
stigmem-node contains an insecure default configuration vulnerability that allows federation traffic to traverse networks without mTLS protection when non-loopback endpoints are enabled. Operators who explicitly disabled mTLS while binding federation to non-loopback addresses expose federation traffic to cleartext interception and man-in-the-middle attacks.
stigmem before 0.9.0a2 Authentication Bypass via Disabled Auth
stigmem versions before 0.9.0a2 allow unauthenticated access when authentication is disabled on non-loopback deployments. Attackers can perform read, write, and federation operations with anonymous identity when nodes are exposed outside local development environments.
stigmem-node 0.9.0a1 accepts federation peer key material during peer registration without a separate administrator out-of-band fingerprint approval step. On nodes that accept federation peer registration over a network where initial registration can be intercepted or misdirected, an attacker can register a malicious peer and gain access to or tamper with federation traffic. Fixed in 0.9.0a2, which introduces a pending approval flow requiring administrator fingerprint verification before peer tokens are accepted.
stigmem Plugin Signature Enforcement Bypass via Configuration
stigmem-node 0.9.0a1 allows plugin signature enforcement to be disabled via a single configuration flag without a second explicit acknowledgment. If that setting is carried into an environment where plugin directories are writable by less-trusted users, unsigned (potentially malicious) plugin code could be loaded and executed, resulting in arbitrary code execution. Fixed in 0.9.0a2, which requires a second explicit acknowledgment to disable signature enforcement.
stigmem Postgres SQL Injection via Schema Identifier
stigmem-node 0.9.0a1 interpolates Postgres backend schema identifiers into SQL strings without defensive quoting. In the affected code path the schema value is operator-controlled, but the unsafe pattern could allow SQL injection if a schema name were derived from tenant, request, or user input. Fixed in 0.9.0a2, which adds identifier quoting and validation. As a workaround, only configure schema names from trusted deployment configuration.
Stigmem before 0.9.0a11 SSRF via unvalidated webhook delivery_address
Stigmem before 0.9.0a11 fails to validate the delivery_address parameter when creating webhook subscriptions, allowing authenticated users to specify internal loopback and private network destinations. Attackers can trigger matching fact-change events to cause the Stigmem server to issue server-side HTTP POST requests to internal services, enabling blind SSRF attacks against localhost and private network endpoints.
stigmem before 0.9.0a12 Cross-Tenant BOLA via decay sweep
stigmem versions before 0.9.0a12 contain a broken object level authorization vulnerability in the decay sweep endpoint that allows authenticated attackers with write credentials for one tenant to execute decay operations affecting all tenants. Attackers can submit POST requests to the decay sweep endpoint with ttl_seconds=0 to expire facts across all tenants, or use dry_run to obtain cross-tenant fact counts and existence information.
stigmem before 0.9.0a12 Cross-Tenant BOLA via quarantine
stigmem-node before 0.9.0a12 contains a broken object level authorization (cross-tenant BOLA) vulnerability in the quarantine review endpoints. On multi-tenant deployments running the opt-in stigmem-plugin-multi-tenant, the list/count queries and _get_quarantined_fact in routes/quarantine.py lacked a tenant_id predicate and the garden lookup was not tenant-scoped, allowing a tenant administrator with only a plain tenant write capability to list, read, and admit or reject quarantined facts belonging to other tenants via the /v1/quarantine endpoints. Default single-tenant deployments are not affected.
stigmem before 0.9.0a12 Cross-Tenant BOLA via Tombstones
stigmem-node before 0.9.0a12 contains a cross-tenant broken object level authorization (BOLA) flaw in the RTBF (right-to-be-forgotten) tombstone mechanism. issue_tombstone defaulted the tenant to "default" instead of the caller's tenant, allowing deletion records to be written to the wrong tenant, and the read-suppression path (_get_tombstone_filter and the tombstone scope cache) lacked a tenant_id predicate, so tombstone suppression was applied tenant-blind across fact queries and provenance reads. As a result, a tenant's deletion could be attributed to the wrong tenant and tombstone suppression could either hide facts belonging to other ten
GitPython before 3.1.58 Path Traversal via .gitmodules Submodule Name
GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.
GitPython before 3.1.58 Config Injection via option-name
GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.
GitPython before 3.1.58 Command Execution via split_single_char_options
GitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.
GitPython before 3.1.58 Arbitrary File Overwrite via read-tree
GitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.
GitPython before 3.1.58 Remote Code Execution via Repo.init
GitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.
GitPython before 3.1.58 Arbitrary File Read via pathspec-from-file
GitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.
linuxfabrik-lib: Arbitrary root file read via live --test argument (lib.lftest) across sudoers-whitelisted plugins (LPE)
linuxfabrik-lib provides Python modules for database access, caching, shell execution, and API integrations, and Linuxfabrik Monitoring Plugins uses its shared testing helper across check plugins. Prior to linuxfabrik-lib 6.1.0 and Linuxfabrik Monitoring Plugins 7.0.0, lib.lftest.test() treated the first or second element of a --test CSV argument as a filesystem path and returned the file contents as simulated standard output or standard error without path confinement. The hidden but production-accessible --test argument was accepted by sudo-authorized plugins, so an attacker controlling the nagios or icinga account could use check-plugins/de