Hello, thanks for tagging me and sorry for the slight delay, I've been swamped with work. I will give it a look now.

So with this change if you force users to pass the template arguments via { context: { ... } } that should stop the attack, but I think this is not whats happening from my understanding of the code. If the user supplies an object that does not have the context handlebars just creates a default one and proceeds with the rendering:

	async renderView (viewPath, options = {}, callback = null) {
		const context = options.context || {};
    }

My concern would be that users that call res.render("name", taintedObject) are still vulnerable because taintedObject can be made in a way that it has the context key recently introduced and they still can override the same set of properties that allow for the bug to happen.

The problem with trying to fix this is that the problem is at three different levels, first the user uses the express render method in a way that is dangerous, second express merges the object passed by the user with data that is intended to be used by the underlying template engine, and third the renderer assumes that the configuration data comming from express is trustworthy.

In my opinion the most balanced way to fix this is to warn clients of handlebars to never pass objects whose keys are attacker controlled to the render method. This also has the benefit of not breaking the API for your users.

This is what eta did to address the same issue here, https://eta.js.org/docs/examples/express while they wait for express to implement a better API for the next big release.

Until then, I can't imagine a proper solution to the issue.

Let me know what you think!

Thanks! I added a note to the readme about this.

I'm going to hold off on this type of change until express fixes their API. Express v5 has been in alpha for almost 7 years 🤞 they will release it one of these days 🤣.

Fantastic @UziTech thank you for your time addressing this issue!

Is it still neccessary to put template variables in a context object when passing to the render method? Can't find anything about that in the current documentation.

If yes, is it right that i need to access these variables in the handlebar template by calling {{context.myvariable}}?

@bavarianbytes no this change was not merged as it didn't fix the underlying vulnerability. The documentation should be correct.