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
linuxfabrik-lib: Local privilege escalation using embedded command
linuxfabrik-lib provides Python modules for database access, caching, shell execution, and API integrations, and Linuxfabrik Monitoring Plugins uses those modules to run external monitoring commands. From the earliest affected releases until linuxfabrik-lib 5.0.0 and Linuxfabrik Monitoring Plugins 6.0.0, check plugins embedded user-controlled values in command strings passed to lib.shell.shell_exec(), which split strings at pipe characters and executed the resulting commands. In check-plugins/restic-check/restic-check, the --repo parameter could inject a pipe-delimited command into a constructed restic invocation, and sudo-authorized executio
linuxfabrik-lib: Insecure creation of SQLite databases
linuxfabrik-lib provides Python modules for database access, caching, shell execution, and API integrations. Prior to version 4.2.0, db_sqlite.py created SQLite databases at predictable paths in the shared /tmp directory and followed attacker-created symbolic links at those paths. An attacker who controls a local monitoring account can create a symlink such as /tmp/linuxfabrik-monitoring-plugins-docker-stats.db and then trigger a sudo-authorized plugin, causing the root process to create or modify the symlink target. The primitive can overwrite arbitrary paths, cause denial of service, or manipulate an existing SQLite database through a craft
Linuxfabrik Monitoring Plugins provides monitoring plugins for Icinga, Nagios, and related systems. Prior to version 5.1.0, the shipped assets/sudoers/Debian.sudoers policy allowed the nagios or icinga account to execute /usr/bin/apt-get as root without restricting its arguments. An attacker who already controls that monitoring account can supply the APT::Update::Pre-Invoke option to execute an arbitrary command while apt-get runs with root privileges, resulting in a root shell and complete compromise of the host. The vulnerable rule supports the check-plugins/deb-updates/deb-updates plugin, but it authorized arbitrary apt-get argument sequen
Lemur: Any user can revoke arbitrary certificates at the CA by uploading a duplicate record and revoking it
Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under th
Lemur: Missing authorization check on POST /certificates/<id>/export for plugins with requires_key = False
Lemur manages TLS certificate creation. Prior to 1.9.3, CertificateExport placed its CertificatePermission ownership check inside the plugin.requires_key branch for POST /api/1/certificates//export. A plugin declaring requires_key false bypassed that check, and the handler still passed cert.private_key as an argument and recorded a key_view audit event. The bundled JavaTruststoreExportPlugin ignored the key, so the immediate exposure was limited to public certificate material and misleading audit entries, but a future plugin could have consumed the supplied key. The fix passes no private key to plugins that do not require one and confines own
Lemur: Sub-CA creation never checks `AuthorityPermission` on the parent authority
Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/authorities with type=subca did not require AuthorityPermission on the parent authority when ADMIN_ONLY_AUTHORITY_CREATION was false. AssociatedAuthoritySchema resolved the caller-supplied parent and passed it through authority creation to cryptography-issuer, which used the parent authority_certificate.private_key to sign a new intermediate. Any authenticated non-read-only user in that supported configuration could chain a sub-CA to an internal root for which the user held no role. The resulting intermediate could issue trusted certificates and its private key could be used
Lemur: Server-Side Request Forgery via the ACME client following server-controlled URLs
Lemur manages TLS certificate creation. Prior to 1.9.3, an authority-role member could update acme_url through PUT /api/1/authorities/ without revalidation and direct setup_acme_client_no_retry to an attacker-controlled ACME server. ACME directory and order responses contain newNonce, newOrder, authorizations, and finalize URLs chosen by that server. The Lemur ClientV2 followed those URLs without requiring their host to match the configured directory host, allowing JWS-signed requests to internal services or cloud metadata endpoints. The issue required an ACME authority and a user authorized for that authority, but did not require global admi
Lemur: Incomplete fix for CVE-2026-55166 -- ACME authority update endpoint allows non-admin to replace `acme_url` with internal IP, bypassing allowlist
Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_acme_url enforced ACME_DIRECTORY_HOST_ALLOWLIST when an authority was created, but PUT /api/1/authorities/ passed options to lemur/authorities/service.py without applying the same check. A user holding an authority role could replace the stored acme_url with an internal service or instance-metadata URL such as 169.254.169.254. The next issuance operation loaded that value and passed it to ClientV2.get_directory, causing an outbound request from the Lemur backend. This bypassed the creation-time mitigation for CVE-2026-55166 and could expose internal services or cloud metadata.
Lemur: Authenticated low-privilege users can read plaintext destination credentials (SFTP password / private-key passphrase) via the destinations API
Lemur manages TLS certificate creation. Prior to 1.9.3, GET /api/1/destinations and GET /api/1/destinations/ relied only on authentication while sibling write handlers required admin_permission. DestinationOutputSchema returned raw options and copied them into pluginOptions without redacting sensitive values. The sftp-destination plugin stored password and privateKeyPass values in plaintext, allowing even a read-only user to retrieve credentials for remote certificate-deployment hosts. The exposed credentials could permit direct access to SFTP systems and TLS material outside the Lemur security boundary. The fix requires administrator permiss
Lemur: Unchecked `replaces[]` lets any user silence notifications and hijack auto-rotation for arbitrary certificates
Lemur manages TLS certificate creation. From 0.5.0 until 1.9.3, certificate create, upload, and edit requests accepted replaces[] or replacements identifiers that AssociatedCertificateSchema resolved with fetch_objects without a CertificatePermission check. Assigning those objects to Certificate.replaces invoked an append listener that disabled the victim certificate notifications and marked it as replaced. The victim was then excluded from get_all_pending_reissue, and certificate_rotate could deploy the attacker certificate to endpoints serving the victim. An authenticated non-read-only user could target certificates for which the user had n
Lemur: SSRF protection in certificate revocation checking bypassable via HTTP redirects and DNS rebinding (incomplete fix for CVE-2026-55162)
Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_revocation_url in lemur/certificates/verify.py checked the original CRL or OCSP URL but the later request could reach a different destination. The CRL requests.get call followed HTTP redirects without validating each Location target, so a public attacker-controlled URL could redirect to loopback, RFC1918, link-local, or instance-metadata addresses. Validation and connection also performed separate DNS resolutions, creating a time-of-check time-of-use window for DNS rebinding on both CRL and OCSP paths. An operator uploading a certificate through POST /api/1/certificates/upload
Lemur: Plaintext password storage in Lemur user-update path
Lemur manages TLS certificate creation. Prior to 1.9.2, lemur.users.service.update assigned a replacement password directly to users.password, while lemur/users/models.py registered User.hash_password only for the before_insert event. Because no before_update listener ran, administrator-initiated password changes through PUT /api/1/users/ were committed as plaintext. The affected user could no longer authenticate normally because bcrypt verification received an unhashed value. A database, backup, replica, query-log, or administrative read compromise exposed immediately usable credentials without offline cracking. The fix registers hashing for
Lemur: Post-authentication SSRF via certificate verification - attacker-controlled CRL and OCSP URLs in uploaded certificates
Lemur manages TLS certificate creation. Prior to 1.9.2, lemur/certificates/verify.py accepted CRL Distribution Point and OCSP responder URLs from uploaded certificate extensions and used them in crl_verify and ocsp_verify without adequate destination validation. An authenticated operator could submit a certificate through POST /api/1/certificates/upload and cause verify_string to reach loopback, RFC1918, link-local, or instance-metadata destinations such as 169.254.169.254. The requests could probe internal services and create side effects from the Lemur host network position. The CRL path also used an unbounded cache, allowing attacker-contr
Lemur: any SSO-authenticated user achieves AWS IAM compromise and permanent PKI key access via ACME acme_url SSRF and creator-equality IDOR
Lemur manages TLS certificate creation. Prior to 1.9.2, authenticated users could influence an ACME authority acme_url without an effective server-side destination restriction and trigger AcmeHandler.setup_acme_client to make backend requests. An attacker could target cloud instance metadata or internal services from Lemur network context, potentially obtaining credentials available to the host. The advisory also identifies creator-equality authorization behavior that could preserve access to certificate key material after ownership or role changes, with insufficient export_private_key audit context to distinguish that access path. Together,
Lemur: Privilege escalation via PUT /api/1/roles/<id> — non-admin role members can rewrite role membership
Lemur manages TLS certificate creation. Prior to 1.9.2, PUT /api/1/roles/ in lemur/roles/views.py:298 authorized updates with RoleMemberPermission(role_id), which allowed either an administrator or any existing member of the target role. The handler passed data["users"] and data["name"] to service.update, allowing a non-admin member to add or remove other users and rename the role. This enabled lateral privilege grants within roles that control certificate and authority access and could deny access by removing legitimate members. The DELETE handler already required admin_permission, confirming that the weaker PUT authorization was inconsisten
Lemur : JWT verifier trusts attacker-supplied alg from token header — defense-in-depth gap; chain-dependent ATO with secret disclosure
Lemur manages TLS certificate creation. Prior to 1.9.2, the JWT verifier in lemur/auth/service.py:130-137 used fetch_token_header to read header_data["alg"] from an unverified token and passed that attacker-controlled value to decode_with_multiple_secrets. PyJWT 2.x rejects alg=none with the configured key, so the flaw is a defense-in-depth gap rather than a direct authentication bypass in the shipped configuration. The unpinned algorithm can become exploitable after an asymmetric-signing migration through algorithm confusion, and it weakens algorithm-based anomaly detection because the token chooses the recorded value. A separate disclosure
Lemur: Authorization bypass in StrictRolePermission / AuthorityCreatorPermission
Lemur manages TLS certificate creation. Prior to 1.9.1, StrictRolePermission and AuthorityCreatorPermission in lemur/auth/permissions.py call flask_principal.Permission.__init__() with zero Need objects when ADMIN_ONLY_AUTHORITY_CREATION and LEMUR_STRICT_ROLE_ENFORCEMENT are unset because both flags default to False. Flask-Principal Permission.allows() returns True when self.needs is empty, so the .can() authorization gate permits every authenticated identity, including the read-only role. A read-only user can access POST /api/1/authorities, POST /api/1/certificates/upload, POST /api/1/pending_certificates//upload, POST /api/1/notifications,