What changed
tinyjs shipped a cluster of security releases between September 28 and October 4, 2026, including versions 0.46.0, 0.47.0 and 0.47.1. The latest fix blocks malformed page messages from bypassing the runtime’s API capability gate and executing with the app’s permissions or triggering its event handlers. The same audit cycle fixed a CORS-open media proxy that could expose arbitrary web or local-network URLs, privileged file:// window paths, cross-user Windows named-pipe exposure, Linux iframe origin confusion, sensitive debug traces and other boundary failures. An earlier September 29 fix closed a newline injection in page-controlled window IDs that could become launcher commands and, on macOS, execute shell commands through AppleScript.
Why it matters
tinyjs deliberately gives a JavaScript backend full system access while rendering the frontend in the operating system’s native webview. That makes its origin and capability boundary the security-critical part of the architecture, especially for apps wrapping hosted websites or embedding third-party frames. The project explicitly tells users of wrapped sites or api.origins to update to 0.47.1. This is also a useful small-project story because the releases show an early runtime rapidly tightening its threat model after external review rather than treating security issues as isolated bugs.
The latest bug bypassed the API gate itself
In 0.47.1, tinyjs changed all three platform launchers so malformed page messages are dropped before reaching the backend. The project says a restricted wrapped page or iframe could previously craft a message that bypassed the api gate, ran with the application’s permissions or invoked the application’s own event handlers. For a runtime built around controlled page-to-native RPC, that is a material boundary failure.
The audit found more than one route across the boundary
Version 0.47.0 restricted tiny.proxyURL after the project found that its CORS-open media proxy could fetch arbitrary HTTP(S) and local-network URLs for any page able to reach it. The same release routes external URL schemes through an explicit navigation policy, changes the updater so the tinyjs website no longer supplies executable installer code on every update, and redacts clipboard and keychain values from debug traces.
Local-machine isolation also needed work
Version 0.46.0 fixed a window-opening path that could turn a hostile page into a privileged local file window. On Windows it made single-instance and private app/window pipes user-specific and authenticated so another local account could not intercept OAuth callbacks, file paths or application traffic. On Linux it tightened iframe message handling so a cross-origin frame could not inherit the trusted top page’s API origin.
A page-controlled newline could become a shell command on macOS
Version 0.42.3 fixed a launcher command-injection issue in window IDs. Newlines could split the runtime’s launcher protocol and make the second line execute as a command. The project says the injection worked across platforms and that on macOS the reachable command set included AppleScript, allowing shell-command execution as the current user.
The project is small by design and still maturing
tinyjs uses the platform webview rather than bundling Chromium and says shipped apps are around 6MB. macOS is described as stable while Windows and Linux remain beta. The same minimal architecture that makes the runtime attractive also concentrates trust in a small launcher/RPC surface, making the recent audit and update cadence especially relevant to early adopters.