Focus on franklioxygen vulnerabilities and metrics.
Last updated: 15 Feb 2026, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with franklioxygen. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total franklioxygen CVEs: 4
Earliest CVE date: 19 Jan 2026, 21:15 UTC
Latest CVE date: 24 Jan 2026, 00:15 UTC
Latest CVE reference: CVE-2026-24140
30-day Count (Rolling): 4
365-day Count (Rolling): 4
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 4 |
| 4.0-6.9 | 0 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for franklioxygen, sorted by severity first and recency.
MyTube is a self-hosted downloader and player for several video websites. Versions 1.7.78 and below have a Mass Assignment vulnerability in the settings management functionality due to insufficient input validation. The application's saveSettings() function accepts arbitrary key-value pairs without validating property names against allowed settings. The function uses Record<string, any> as input type and iterates over all entries using Object.entries() without filtering unauthorized properties. Any field sent by the attacker is directly persisted to the database, regardless of whether it corresponds to a legitimate application setting. This issue has been fixed in version 1.7.78.
MyTube is a self-hosted downloader and player for several video websites. Versions 1.7.78 and below do not safeguard against authorization bypass, allowing guest users to download the complete application database. The application fails to properly validate user permissions on the database export endpoint, enabling low-privileged users to access sensitive data they should not have permission to view.
MyTube is a self-hosted downloader and player for several video websites. Prior to version 1.7.71, a rate limiting bypass via `X-Forwarded-For` header spoofing allows unauthenticated attackers to bypass IP-based rate limiting on general API endpoints. Attackers can spoof client IPs by manipulating the `X-Forwarded-For` header, enabling unlimited requests to protected endpoints, including general API endpoints (enabling DoS) and other rate-limited functionality. Version 1.7.71 contains a patch for the issue.
MyTube is a self-hosted downloader and player for several video websites. A vulnerability present in version 1.7.65 and poetntially earlier versions allows unauthenticated users to bypass the mandatory authentication check in the roleBasedAuthMiddleware. By simply not providing an authentication cookie (making req.user undefined), a request is incorrectly passed through to downstream handlers. All users running MyTube with loginEnabled: true are impacted. This flaw allows an attacker to access and modify application settings via /api/settings, change administrative and visitor passwords, and access other protected routes that rely on this specific middleware. The problem is patched in v1.7.66. MyTube maintainers recommend all users upgrade to at least version v1.7.64 immediately to secure their instances. The fix ensures that the middleware explicitly blocks requests if a user is not authenticated, rather than defaulting to next(). Those who cannot upgrade immediately can mitigate risk by restricting network access by usi a firewall or reverse proxy (like Nginx) to restrict access to the /api/ endpoints to trusted IP addresses only or, if they are comfortable editing the source code, manually patch by locating roleBasedAuthMiddleware and ensuring that the logic defaults to an error (401 Unauthorized) when req.user is undefined, instead of calling next().