# Security of Julia, since possible to change the compiler at runtime
**URL:** https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199
**Category:** Internals & Design
**Created:** [September 3, 2026, 11:27pm UTC](https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199 "2026-09-03T23:27:05Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [September 3, 2026, 11:27pm UTC](https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199/1 "2026-09-03T23:27:05Z")
Continuing the discussion from [This month in Julia World - 2026-08](https://discourse.julialang.org/t/this-month-in-julia-world-2026-08/139157):
> [@This month in Julia World - 2026-08](https://discourse.julialang.org/t/this-month-in-julia-world-2026-08/139157/1):
>
> - security researcher Tsi-Lin Ng and others managed to backdoor the infrastructure behind the package managers for Python, Go, Flutter, and … Julia.
> He gave a presentation on the exploit at Black Hat 2026, the [slides for which are publicly available](https://i.blackhat.com/BH-USA-26/Presentations/US-26-SplitlineNg-BornCorrupted-Thursday.pdf).
> Rebuilding the Julia infrastructure to fix the issue took extra time since
Slide 48
Not too surprising. If you have access to the compiler (or infrastructure), then you can change the generated code:
> **[Reflections on Trusting Trust](https://aeb.win.tue.nl/linux/hh/thompson/trust.html)**
We can already change the parser at runtime. I believe we can also change the compiler in arbitrary ways. E.g. a package could?
Is there any way around this in Julia or languages like Lisp? Even Python? Can and should the compiler be code that is is a separate process? An .so/.dll? could you still unload it and load a new one from the REPL?
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [September 4, 2026, 12:42am UTC](https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199/2 "2026-09-04T00:42:41Z")
Hmmm. As soon as you load a package, its ` __init__ ()` function runs, which can run arbitrary code, right? So a malicious package can just run malicious code in ` __init__ ()` - no need to change the compiler.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 4, 2026, 7:57am UTC](https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199/3 "2026-09-04T07:57:33Z")
> [@dilumaluthge](#):
>
> As soon as you load a package, its ` __init__ ()` function runs, which can run arbitrary code, right?
Precompilation can also run arbitrary code even if it’s not cacheable, not nearly as restricted as typical AOT compile-time computation.
> [@Palli](#):
>
> Can and should the compiler be code that is is a separate process?
Not generally feasible to send all the information about the current process over to another one, and the new process can be hacked anyway. Precompilation does this, but only by reusing identifiable caches.
> [@Palli](#):
>
> We can already change the parser at runtime. I believe we can also change the compiler in arbitrary ways. E.g. a package could?
I was under the impression the compiler backend couldn’t be swapped out without lower-level injection, but not sure about the frontend. I too would like to know if it’s possible for the default parser+compiler to be ruined at runtime.
That wouldn’t actually be unusual because we can already break the runtime with very little type piracy. Julia can be written in Julia very deep down, and there’s very rarely any deterrence of new world ages. For comparison, I can straightforwardly redefine `Float64` addition, changing backspacing in an empty REPL line as a side effect:
```julia-auto
julia> Base.:+(x::Float64, y::Float64) = (println("hi"); Base.add_float(x, y))
julia> 1.2 + 3.4
hi
4.6
julia> hi
julia> hi
```
but I run into a frozen class feature when trying a similar thing in Python:
```julia-auto
>>> def blah(self, x): pass # not going to bother with a hack
...
>>> float. __add__ = blah
Traceback (most recent call last):
File "", line 1, in
float. __add__ = blah
^^^^^^^^^^^^^
TypeError: cannot set ' __add__' attribute of immutable type 'float'
```
A higher reliance on compiled C also protect lower-level implementations. Still, any dynamic language implementing itself on any level is vulnerable to really bad monkey patching:
```julia-auto
>>> import builtins
>>> oldabs = builtins.abs
>>> def newabs(x): return -oldabs(x)
...
>>> builtins.abs = newabs
>>> abs(1.2), abs(-3.4)
(-1.2, -3.4)
```
In conclusion, there’s a lot more to worry about than the parser and compiler, and executing malware is going to hurt regardless.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [September 4, 2026, 1:29pm UTC](https://discourse.julialang.org/t/security-of-julia-since-possible-to-change-the-compiler-at-runtime/139199/4 "2026-09-04T13:29:00Z")
If you can execute some code to change the compiler, you could just as easily execute malware directly. Vulnerabilities don’t live in a vacuum; they _break through_ some trust barrier.
So, yes, it’s very much a huge problem if an attacker can swap out and compromise the things we sign and distribute. That’s breaking a trust barrier: you trust `julialang.org` (and `juliaup`) to serve a good `julia`! It’s not a vulnerability, however, that you can change the `juliaup` config to point to a bad bucket elsewhere on the internet that serves some compromised malware. Don’t download and run things you don’t trust!
Similarly, it’s very much a huge problem if an attacker can use an HTTP connection with a HTTP.jl server to unexpectedly make `+(::Float64, ::Float64)` in that Julia session run `rm -rf ~` instead. That’s breaking a trust boundary! But it’s not a vulnerability that you can shoot yourself in the foot in the same manner at a REPL.