[Vulnerability] Server side template injection leads to RCE
See original GitHub issueHey team, Thank you for this awesome project.
I found a template injection leads to Remote code execution. Using this vulnerability an attacker can update the value of outputFunctionName
to inject a JS code which will be executed with the template compiled function.
I didn’t post the details here, waiting for your confirmation on the right place to report the full details of this vulnerability.
Thanks again, waiting for your response.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
RCE with Server-Side Template Injection | R3d Buck3T
Server -side template injection is a web application vulnerability that occurs in template-generated applications. User inputs get embedded ...
Read more >Server-Side Template Injection: RCE for the modern webapp
Unlike XSS, Template Injection can be used to directly attack web servers' internals and often obtain Remote Code Execution (RCE), turning every vulnerable....
Read more >Server-side template injection | Web Security Academy
Vulnerabilities like this are sometimes caused by accident due to poor template design by people unfamiliar with the security implications. Like in the...
Read more >SSTI (Server Side Template Injection) - HackTricks
A server-side template injection occurs when an attacker is able to use native template syntax to inject a malicious payload into a template,...
Read more >Server Side Template Injection - Cyber Security Consulting
Remote Code Execution. Listen for connexion. nv -lnvp 8000. Exploit the SSTI by calling subprocess.Popen.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@netcode You are 100% correct about that. We should do a much better job of setting expectations in the docs. I am totally underwater with work this week, but I am hoping to have some time this weekend to push out a release. Maybe I can add some caveating to the docs at the same time. Thanks so much for your understanding!
So, what is the outcome of this conversation?
Option 1: The documentation was mostly clear. So, update the docs. Maybe, apply the fix… just in case. Delete the vulnerability report so it doesn’t show up with npm audit. (if the report is still there, it creates additional noise and it’s harder to see what’s really matter)
Option 2: The documentation was misleading so people are likely to be affected by this vulnerability. Then, fix the vulnerability. Because it’s gonna be a major update of the documentation (read interface of the library) , create a new major version where the docs will be changed. (if major version isn’t bumped - nobody notices and continues to use the package according to the old docs)
It looks to me that you’ve chosen Option 1. So @netcode maybe you delete(/decrease the severity level) this report so I don’t see 3 critical errors (somehow it’s getting multiplied) in my console ?