Interesting that the jquery tracker item is from 2015

@brianteeman this issue got some attention recently because Google Lighthouse detects the outdated version and adds a warning to it's report

It only came to my attention because of GitHub's security checks in dependency trees for supported stuff (i.e. package.json for NPM).

Fair enough although if its easily exploitable then I am sure the relevant people already knew

Is this really exploitable in the reality? Please keep in mind that cross domain requests are not allowed by the browsers and someone who can manipulate local ajax responses most likely also
has the ability to manipulate javascript code sent to the client, so in my opinion this change would only create problems for no real reason.

Cross-Domain requests are possible, you only need proper CORS headers on the requested endpoint.

Which means you need access to the endpoint server (or ability to reroute traffics to a fake one) - possible, but not very easy to do.

Regardless of this - I see now that In the patch from typo3 execution is disabled only if this is a crossdomain request, perhaps this is worth mentioning in the descripton text as now it reads like you are planning to change the default for all requests. This ofcourse puts this change in a much different light.

Which means you need access to the endpoint server (or ability to reroute traffics to a fake one) - possible, but not very easy to do.

True, it’s a rather special scenario, but not impossible.

I’ll update my description as suggested.

Even BS2 has JS components are vulnerable. There are patches out there.

Posting this for reference as it took a while to find the CVE for this
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2015-9251

Subscribed, Qualys scans just started complaining about this as well.

@SniperSister @mbabker @wilsonge

github has started to flag this as a vulnerability now as well :(

Yes because the privacy-framework repo is a 1:1 copy of the cms and not a fork ;)

@SniperSister @wilsonge has a decision been made about this?

@brianteeman thanks for the reminder, I created a PR

Closed

@brianteeman this issue got some attention recently because Google Lighthouse detects the outdated version and adds a warning to it's report

Me too! And in terms of getting better SEO results, it's important to get a high score and try to eliminate all issues that Google Lighthouse points out. And /media/jui/js/jquery.min.js is running outdated version jQuery v1.12.4. I think this file need some attention, even if it cannot be upgrade for BC reasons. I will try to go for solution in my website template to fix this, by adding an updated version like this: JOOMLA_ROOT/templates/YOURTEMPLATE/js/jui/jquery.min.js

@quercusdk the fix for the issue has already been merged into J 3.9.0

Has the JQuery version been updated, or is it still reported as 1.12.4? I ask because I'm at Joomla! 3.9.18 but Qualys is still complaining about the jQuery version.

Vulnerable javascript library: jQuery
version: 1.12.4
script uri: https://www.xxx.com/media/jui/js/jquery.min.js?efc1895f05399bc1186b1ab0ba6bc8ef

I just want to confirm that the vulnerabilities in jQuery 1.12.4 do not exist in the version of this file included with Joomla! 3.9.18

I can't obtain good lighthouse points with this "patched" JQuery...

Google don't like it, i know that probably is not a ranking factor, but a little of fear exist. A website that can fail a good indexation and positioning is a useless website.

@quercusdk the fix for the issue has already been merged into J 3.9.0

We know it. But Google don't.

If is impossibile to fix beacuse of some BC reasons, maybe Joomla.org can provide some instruction to add a new jQuery version with his "migrate" script for remove this alert.

If is impossibile to fix beacuse of some BC reasons, maybe Joomla.org can provide some instruction to add a new jQuery version with his "migrate" script for remove this alert.

The only way you can get Google or other automated scanning tools to stop raising this alert is to fake the version number in the jQuery library itself to report a non-vulnerable version number (as of today, only jQuery 3.5.0 or later do not have any reported vulnerabilities). Which may or may not have a plethora of other consequences to the jQuery based code that is actually running on your site.

Thank you Simone for bringing this up again.

My customers need security certifications that require successful scans of the website, but these scans fail when Qualys and other scanning tools complain about the jQuery version. My assuring them "Joomla! has backported the fixes, trust me" doesn't work for the certification.

I understand the complications, but is there some sort of plan to get us past these issues?

I understand the complications, but is there some sort of plan to get us past these issues?

The backports are the plan for Joomla 3 because a major upgrade of a JavaScript framework that includes breaking changes isn't going to ship in a stable release. Joomla 4 ships with the latest jQuery version.

Joomla should not be changing the jQuery library version string to appease these types of systems, since it seems they are relying solely on version number sniffing and not actually testing the vulnerabilities in any practical manner. The only way it could do that anyway is to change the string from "1.12.4" to "3.5.0" (or any later non-vulnerable version). That may very well break plugins which rely on version detection of the jQuery library version. If you're one of those people who run on RHEL based systems where Red Hat is continuing to backport security patches onto PHP 5.4, you'll understand exactly what I'm talking about.

You're welcome to upgrade your own site to jQuery 3.5 (or any later non-vulnerable version) by using media overrides. You're also welcome to use the same override mechanisms to manipulate the version string inside jQuery to get those scanners to stop groaning. But Joomla in its role cannot ship jQuery 3.5 in Joomla 3.x, where jQuery 1.x is expected by anyone building anything.

Joomla 4 ships with the latest jQuery version.

Sorry to butt in on a closed issue, @mbabker, but I thought jQuery was being completely dropped from J4 in favour of JavaScript.

but I thought jQuery was being completely dropped from J4 in favour of JavaScript.

The library is still packed in core but not used by core. 3rd extensions can still use it without B\C breaks.

It is still used in a few places although the intention is to remove them eventually