- Bun v1.4.3 adds bun check, a TypeScript type checker that Bun says matches tsc. Teams can use it to stop code with type errors from running, testing or building.
- Bun also says it now enforces a Node flag that blocks eval() and new Function(). Before, Bun accepted the flag and ignored it.
- Ask your teams which security settings have been verified to work, and whether type errors should stop a build.
A security setting that is accepted but does nothing is worse than a missing one. Nobody looks for a gap they believe is closed. Bun's v1.4.3 release shows both sides of this: a new tool whose makers say it matches its reference and publish how they tested that, and a fix for a flag that used to be quietly ignored.
What Bun shipped
Bun, the JavaScript runtime and toolkit, released v1.4.3 on October 10, 2026. Its main addition is bun check, a TypeScript type checker. Bun says it is a port of typescript-go, reads your tsconfig.json and reports the same errors as tsc, the standard TypeScript checker. It uses every CPU core and needs no typescript package installed.
Bun's own timing, taken on one 16-core Apple silicon Mac, has bun check running between 3 and 6.4 times as fast as tsc 7.0.2. That is a vendor benchmark on a single machine. Treat it as a claim to test on your own code.
The gate: type errors can stop the run
The more important change is where the checker can sit. Bun can type check first and run second. If there is a type error, the code does not run. The same applies to tests and to builds. In a build, a type error fails the build and nothing is written.
A type checker finds a class of mistakes before software reaches customers. Once a team puts the check into its run, test and build commands, such as package.json scripts, it no longer depends on habit or deadline. Bun's post shows the form: `bun run --check dev`. Without that step, the check does not happen. The limits matter too. Bun's checker only checks. It does not produce JavaScript or type declaration files, and it has no language server, so editors keep using TypeScript.
How do you trust a rewrite?
A new checker that disagrees with the old one creates noise or false comfort. Bun describes how it tested for that. Every commit runs TypeScript 7.0.2's full conformance suite, and Bun says bun check passes all of it. These are Bun's own results, not an independent audit.
Conformance tests alone did not satisfy Bun. Its team set up broken configurations on purpose in 72 well-known open-source projects, then ran both checkers and compared the results. Each error had to match on file, line, column and error code. Bun reports one mismatch, in vuejs/core, which depends on the order of files in the configuration.
Bun also ran fuzzers that generate combinations of language features. In its larger offline runs, it lists 191 mismatches. Of those, 162 involve code that refers to itself while being declared. For mutation testing, Bun broke the source of the Effect library 913 times and compared every error.
The lesson for buyers is that this is how a replacement should earn trust. It names its test method and its known gaps. Bun adds that any difference from tsc is a bug in Bun.
The flag that did nothing
Among the hardening items is a plain admission. Node has a flag, --disallow-code-generation-from-strings, that makes eval() and new Function() throw errors. Bun says it "used to accept the flag and ignore it." Now the flag works across the whole process, including every Worker.
Bun also adds a Bun-only =strict level. It blocks other ways a string becomes code, such as node:vm, import() of a data: URL and plugins that return source text. If the flag is built into a compiled program, it applies on every run. The BUN_OPTIONS environment variable may make the restriction stricter. It cannot relax one already built in.
Consider the engineer who set that flag during a hardening review. The setting looked applied and the review was signed off. Under the earlier behaviour, nothing was enforced. Bun's post does not report any incident from this. It does show how a control can look present and be absent.
A related fix works the same way. Previously, if a proxy turned down a tunnel request with an error status, fetch() handed back the proxy's refusal as though the destination site had answered. Bun now raises an ERR_PROXY_TUNNEL error instead.
Other hardening in the release
Bun lists many more changes. It tightened how TLS certificate names are matched: only well-formed host names and standard-form IP addresses now qualify (CVE-2026-48618). Servers in node:http2 rate-limit stream resets, covering CVE-2023-44487 and CVE-2025-8671. Bun.SQL treats a certificate file passed as tls or ssl as a trusted authority and uses full verification.
The post does not rank these fixes or say whether any were exploited. Read them as a maintenance record, not a risk assessment.
What to ask your team
First, ask which security flags and settings in your build and runtime have been tested to work, not only set. A test that tries to call eval() with the flag set should be a quick one to write.
Second, decide whether type errors should stop a build. If they should, make that a pipeline rule instead of a habit. If you use Bun, ask whether bun check matches your current tsc output on your own repositories before you switch.
Third, read the release notes of runtimes you depend on for lines that begin with "hardened" or "fixed". They show what your systems were doing before the update.
A control earns trust when someone has watched it say no.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Bun.
