Breaking security release 5.6.36

[staudenmeir]

The security release 5.6.36 escapes the output of @lang calls (d3c0a36). This broke a lot of applications and even Laravel features like the links of simple pagination and the user verification email (#25408, #25430, #25501).

But there is still no additional information on the release (AFAIK), not even a crucial entry in the upgrade guide.

As suggested by @stayallive, can't we just escape the parameters? Shouldn't the application's language files be considered a secure input?

[X-Coder264]

I completely understand breaking stuff for security reasons, but unlike the cookie serialization stuff this didn't even get a tweet, let alone a mention in the documentation even though it broke a huge amount of applications.

[markovic-nikola]

I agree, some heads up should've been given at least, a lot of people now are experiencing this issue and refactoring could take some time.
And days have passed after people complained about this and still no response...

[daniesy]

This is still open after 19 days?

[marcbelletre]

There has been many issues opened about this and I don't understand neither why all of them are still ignored.
I stopped updating my Laravel apps since this release because it would take so much time to replace everything. Of course I could just search and replace every @lang() directive with {!! __() !!} but this would make no sense for two reasons:

• This would reintroduce the XSS vulnerability
• This would be totally useless for strings that do not contain any HTML

The best way would be to do the replacement only for strings containing HTML, which would take way too much time and would result in a very ugly code mixing two different syntaxes.

@at-dro proposed a solution 10 days ago in #25408 that sounds good. Is there any chance this could be implemented?

[stayallive]

I for now reverted the change by replacing the ViewServiceProvider with: #25408 (comment).

Until I am able to replace all occurrences and/or a fix or comment saying there won't be a fix comes... this at least allows me to move forward and keep being up-to-date with Laravel 5.7.

[daniesy]

I gave up wishing for a fix and removed @lang throughout all my projects. I find the @lang update kind of ... let's call it unwise (they made @lang secure by removing functionality and now users are forced to actually write insecure code on purpose so that all their projects don't break), but hey, I'm not running Laravel, so what do I know?

Anyway, I've devised some regex to replace @lang with {!! __() !!} . They're not perfect, but they did the job.

Step1: Remove simple @lang usage
Search for: @lang\(['"]([^'|^"]+)['"]\)
Replace with: {!! __('$1') !!}

Step2: Remove @lang with parameters
Search: @lang\((['"][^'|^"]+['"][ ]{0,},[ ]{0,}\[['"][^\]]+\])\)
Replace with: {!! __($1) !!}

Be sure to make a commit before doing the replacements, in case something breaks.

[drakakisgeo]

I downgraded and locked the laravel-framework dependency. I will wait a few weeks more for this one, it really broke everything in so many ways.... so I'll hope a clean solution will be found, before renaming everything.

[markovic-nikola]

I downgraded and locked the laravel-framework dependency. I will wait a few weeks more for this one, it really broke everything in so many ways.... so I'll hope a clean solution will be found, before renaming everything.

Same here

[taylorotwell]

I'm reverting this entire dumpster fire. Will just document if you use @lang its up to you to escape.