355,769
Total CVEs
25,065
Critical
81,857
High
1,609
CISA KEV
113
This Week
239 results · Page 1/10
FreePBX is an open source IP PBX. In versions below 16.0.71 and 17.0.6, the backup module does not properly sanitize data during restore operations, potentially leading to compromise if the backup contains carefully crafted hostile data. During backup restore operations, FreePBX extracts selected files from a user-supplied tar archive. If a malicious file exists in the archive, it is read and passed directly to unserialize() without validation, class restrictions, or integrity checks. This issue allows Remote Code Execution during restoration of the backup as the web server user (typically asterisk or www-data). The attack does not require shell access, CLI access, or filesystem write permissions beyond the normal restore workflow. Authentication with a known username that has sufficient access permissions and/or write access to backup files is required. This issue has been fixed in versions 16.0.71 and 17.0.6.
An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14. `django.middleware.cache.UpdateCacheMiddleware` erroneously caches requests where the `Vary` header contained an asterisk (`'*'`). This can lead to private data being stored and served. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Ahmad Sadeddin for reporting this issue.
djangoproject
FreePBX is an open-source web-based graphical user interface (GUI) that manages Asterisk. Prior to 17.0.5 and 16.0.17, FreePBX module api (PBX API) is vulnerable to privilege escalation by authenticated users with REST/GraphQL API access. This vulnerability allows an attacker to forge a valid JWT with full access to the REST and GraphQL APIs on a FreePBX that they've already connected to, possibly as a lower privileged user. The JWT is signed using the api-oauth.key private key. An attacker can generate their own token if they possess this key (e.g., by accessing an affected instance), and specify any scopes they wish (e.g., rest, gql), bypassing traditional authorization checks. However, FreePBX enforces that the jti (JWT ID) claim must exist in the database (api_access_tokens table in the asterisk MySQL database) in order for the token to be accepted. Therefore, the attacker must know a jti value that already exists on the target instance. This vulnerability is fixed in 17.0.5 and 16.0.17.
sangoma
