CVE-2026-106105 in ssl-certificate
Summary
by MITRE • 10/06/2026
Quasar Framework is a framework for building high-performance Vue.js user interfaces. Prior to @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4, and @quasar/app-vite 3.3.0, the @quasar/ssl-certificate utility cached a combined private key and certificate PEM without explicitly applying owner-only filesystem permissions. Another local user able to read the cache can copy the key and impersonate a development TLS endpoint in an environment that trusts the certificate. The generated certificate was also CA-capable, carried unnecessarily broad key usages, and encoded the IPv6 loopback address as a DNS subject alternative name. This issue is fixed in @quasar/ssl-certificate 2.1.0, @quasar/cli 5.0.4, and @quasar/app-vite 3.3.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Quasar Framework serves as a robust toolset for developing high-performance user interfaces using Vue.js, but its underlying development utilities have historically exhibited security weaknesses in how they handle cryptographic materials during local server operations. Specifically, prior to the release of quasar/ssl-certificate version 2.1.0, quasar/cli version 5.0.4, and @quasar/app-vite version 3.3.0, the ssl-certificate utility contained a critical flaw in its file system management practices when generating self-signed certificates for local development environments. The core technical deficiency lies in the method used to store the generated private key and certificate bundle. Instead of creating these sensitive files with restrictive permissions that limit access exclusively to the owning user, the utility cached the combined PEM-encoded data without explicitly applying owner-only filesystem permissions. This oversight results in a state where other local users on the same system can read the contents of the cache file, thereby gaining unauthorized access to the private key material associated with the development TLS endpoint.
This vulnerability creates a significant risk for developers working in shared or multi-user environments, such as corporate workstations, university labs, or CI/CD runners that may not strictly isolate user contexts. An attacker with local account privileges can exploit this misconfiguration by reading the cached certificate and private key files. Once obtained, these credentials allow the attacker to impersonate the development TLS endpoint in any environment where the generated self-signed certificate is trusted. This capability effectively enables a man-in-the-middle attack scenario against other users or services that rely on the same local host for secure communication during development. The impact extends beyond simple data interception; it compromises the integrity and authenticity of the local development server, potentially allowing the extraction of sensitive session tokens, authentication credentials, or proprietary code being served over HTTPS.
The vulnerability is further exacerbated by additional design flaws in the generated certificate itself. The utility produced certificates that were CA-capable, meaning they could be used to sign other certificates, which violates the principle of least privilege for a development tool intended only for local testing. Furthermore, the key usage extensions were unnecessarily broad, granting permissions beyond what was strictly required for TLS server authentication. These factors increase the blast radius if the credentials are compromised, as an attacker could theoretically use the private key to forge additional certificates trusted by the system's certificate store. Additionally, the implementation encoded the IPv6 loopback address (::1) as a DNS subject alternative name rather than using the appropriate IP address type for SANs. While this is primarily a configuration inconsistency that may cause compatibility issues with strict TLS implementations or validation libraries, it reflects a lack of precision in cryptographic object construction and adherence to standard encoding practices defined by RFC 5280.
From an industry standards perspective, this issue maps directly to CWE-732: Incorrect Permission Assignment for Critical Resource, as the file system permissions were not set correctly to restrict access to sensitive data. It also aligns with CWE-916: Use of Key Block for Multiple Purposes, given that a single key pair was generated with overly broad usages including CA capabilities when only server authentication was intended. In terms of attack vectors and tactics, this vulnerability facilitates the MITM (Man-in-the-Middle) technique described in the ATT&CK framework under T1557, specifically involving Adversary-in-the-Middle scenarios where an attacker intercepts communication between two parties who believe they are directly communicating with each other. The ability to impersonate a local service also touches upon credential harvesting and session hijacking tactics if sensitive data is transmitted over the compromised channel.
To mitigate this vulnerability, developers must ensure that their development environments utilize patched versions of the Quasar tooling ecosystem. Upgrading quasar/ssl-certificate to version 2.1.0 or later, along with corresponding updates to quasar/cli (5.0.4+) and @quasar/app-vite (3.3.0+), resolves the permission issue by ensuring that generated private keys are stored with owner-only read/write permissions. This prevents other local users from accessing the cryptographic material. For organizations or teams operating in shared environments, it is also advisable to implement additional safeguards such as using dedicated virtual machines or containers for development work where user isolation is enforced at a higher level than standard file system permissions. Regular auditing of certificate generation practices and ensuring that self-signed certificates are strictly limited to server authentication without CA capabilities should be part of the security hygiene routine for any team utilizing these frameworks.