CRITICAL: Memory Leak in Blob URL Management - Denial of Service Vulnerability
Summary
Reframe has a critical memory leak vulnerability where blob URLs created during video processing are not consistently revoked, leading to unbounded memory growth and potential browser crashes. This violates the application's privacy promise by keeping user video data in memory indefinitely.
Vulnerability Details
Location
- src/lib/ffmpeg.worker.ts line 87: Creates blob URL for FFmpeg core files but never revokes
- src/lib/ffmpeg.ts line 113: Creates blob URL for export result but revocation depends on user action
- src/components/VideoPreview.tsx line 77: Creates blob URL for video preview, cleanup only on unmount
- src/hooks/useVideoEditor.ts line 16: Creates blob URL for metadata extraction, cleanup only on success/error
The Issue
-
FFmpeg Core Files: The worker creates blob URLs for FFmpeg core files (JS, WASM, worker) but never revokes them. Each export creates new blob URLs that persist for the lifetime of the worker.
-
Export Results: Export blob URLs are only revoked when:
- User starts a new export
- Component unmounts
- Settings are reset
If a user exports multiple times without these actions, blob URLs accumulate.
-
Video Preview: Blob URLs are created for video preview but only cleaned up on component unmount. Rapid file changes without unmount cause accumulation.
-
Metadata Extraction: Blob URLs for metadata extraction are only revoked on success/error. If the promise hangs (e.g., corrupted video), the URL leaks.
Attack Scenario
- Attacker uploads a specially crafted video that causes metadata extraction to hang
- Blob URL is created but never revoked
- Attacker repeats this process, consuming browser memory
- Browser becomes unresponsive or crashes (DoS)
- User loses all unsaved work
Impact
- Memory Exhaustion: Each blob URL holds reference to potentially large video files (up to 2GB)
- Browser Crash: Accumulated memory pressure can crash the browser tab
- Data Loss: Unsaved work lost when browser crashes
- Privacy Violation: Blob URLs persist in memory even after user navigates away, keeping user video data accessible in browser memory
Severity
CRITICAL - CVSS 7.5 (High)
- Attack Vector: Local (user uploads malicious file)
- Impact: High (memory exhaustion, DoS, privacy violation)
- Privileges Required: None
- User Interaction: Required (upload file)
Why This Matters
1. Privacy Betrayal
Reframe's core value is "100% private" processing. Memory leaks mean user video data persists in browser memory indefinitely, accessible to any script running in the same origin.
2. Denial of Service
Users can accidentally (or maliciously) cause browser crashes by processing multiple videos, making the application unusable.
3. Resource Exhaustion
Modern browsers have limits on blob URL storage. Exceeding these limits causes all blob operations to fail, breaking the entire application.
4. Non-Obvious
Memory leaks are insidious - they don't cause immediate failures. The application appears to work correctly until memory pressure builds up over time.
5. Hard to Debug
Memory leaks don't appear in error logs or crash reports. They manifest as "sluggish performance" or "random crashes" that are difficult to trace back to the root cause.
The Fix
Immediate Mitigation
// Track all blob URLs and revoke them systematically
let activeBlobUrls = new Set<string>();
function createTrackedBlobUrl(blob: Blob, mimeType: string): string {
const url = URL.createObjectURL(blob);
activeBlobUrls.add(url);
return url;
}
function revokeAllBlobUrls(): void {
activeBlobUrls.forEach(url => URL.revokeObjectURL(url));
activeBlobUrls.clear();
}
// In worker cleanup
finally {
revokeAllBlobUrls();
for (const path of cleanupFiles) {
await removeFile(path);
}
}
Long-term Solution
- Implement automatic blob URL cleanup with WeakMap
- Add memory monitoring and warnings
- Implement blob URL lifecycle management
- Add cleanup on page visibility change
- Set maximum blob URL limits with graceful degradation
Why This Vulnerability Was Overlooked
- Browser API Design:
URL.createObjectURL creates references that don't automatically clean up
- No Immediate Symptoms: Leaks accumulate over time, not immediately
- Testing Gap: Unit tests don't measure memory usage over time
- Complex Lifecycle: Blob URLs created in multiple contexts (worker, main thread, components)
- Error Path Neglect: Cleanup logic often only tested in success paths
This issue should be prioritized as it directly impacts:
- Application stability (browser crashes)
- User privacy (data persistence in memory)
- Resource management (memory exhaustion)
- User experience (performance degradation over time)
CRITICAL: Memory Leak in Blob URL Management - Denial of Service Vulnerability
Summary
Reframe has a critical memory leak vulnerability where blob URLs created during video processing are not consistently revoked, leading to unbounded memory growth and potential browser crashes. This violates the application's privacy promise by keeping user video data in memory indefinitely.
Vulnerability Details
Location
The Issue
FFmpeg Core Files: The worker creates blob URLs for FFmpeg core files (JS, WASM, worker) but never revokes them. Each export creates new blob URLs that persist for the lifetime of the worker.
Export Results: Export blob URLs are only revoked when:
If a user exports multiple times without these actions, blob URLs accumulate.
Video Preview: Blob URLs are created for video preview but only cleaned up on component unmount. Rapid file changes without unmount cause accumulation.
Metadata Extraction: Blob URLs for metadata extraction are only revoked on success/error. If the promise hangs (e.g., corrupted video), the URL leaks.
Attack Scenario
Impact
Severity
CRITICAL - CVSS 7.5 (High)
Why This Matters
1. Privacy Betrayal
Reframe's core value is "100% private" processing. Memory leaks mean user video data persists in browser memory indefinitely, accessible to any script running in the same origin.
2. Denial of Service
Users can accidentally (or maliciously) cause browser crashes by processing multiple videos, making the application unusable.
3. Resource Exhaustion
Modern browsers have limits on blob URL storage. Exceeding these limits causes all blob operations to fail, breaking the entire application.
4. Non-Obvious
Memory leaks are insidious - they don't cause immediate failures. The application appears to work correctly until memory pressure builds up over time.
5. Hard to Debug
Memory leaks don't appear in error logs or crash reports. They manifest as "sluggish performance" or "random crashes" that are difficult to trace back to the root cause.
The Fix
Immediate Mitigation
Long-term Solution
Why This Vulnerability Was Overlooked
URL.createObjectURLcreates references that don't automatically clean upThis issue should be prioritized as it directly impacts: