Security scan of Matomo 4.13.0 results in several vulnerabilities - Need support

Hi Matomo team,

Interested to proceed with Matomo product, upon scanning the matomo 4.13.0 on-prem-edition with Sonatype for security, several vulnerabilities were identified.
Major one being the usage of Angular JS version 1.8.2. and other includes jquery,material css.

Requesting Matomo team to provide suggestion on this restriction.
Is the matomo server version depends on these angular libraries or it can be removed to use matomo without those feature?
Is there any recommendation from matomo to eliminate this situation
Can these dependencies upgraded to other Angular/jquery version ?
Is there any roadmap from Matomo to upgrade these ?

Attached sonatype report

SonaType Report Page 2

SonaType Report Page3

More Details on the Angular version vulnerability,




Sonatype CVSS 3



Sonatype CWE

Sonatype Data Research



The AngularJS framework is vulnerable to Remote Code Execution (RCE) and Cross-Site Scripting (XSS). The ensureSafeAssignContext() function in parse.js processes malicious expressions that access the constructors. A remote attacker can exploit this vulnerability by crafting malicious expressions that, when processed, result in execution of arbitrary code.


Sandbox escape from 1.3.2 fixed in 1.3.3 by Gareth Heyes (PortSwigger):

My versions modified to work with 1.3.3 - 1.5.7+:
As literal object: {{x = {‘y’:‘’.constructor.prototype}; x[‘y’].charAt=[].join;$eval(‘x=alert(Evaluated Object Literal)’);}}
As Array: {{x = [‘’.constructor.prototype]; x[0].charAt=[].join; $eval(‘x=alert(Evaluated Array)’);}}

In these examples I am able to mask what I’m doing and the expression passes the ensureSafeAssignContext checks.



The application is vulnerable by using this package along with allowing users to control the content of Angular templates and relying on the sandbox for code execution prevention.


Each version of Angular 1 up to, but not including 1.6, contained an expression sandbox, which reduced the surface area of the vulnerability but never removed it. In Angular 1.6 we removed this sandbox as developers kept relying upon it as a security feature even though it was always possible to access arbitrary JavaScript code if one could control the Angular templates or expressions of applications.
Control of the Angular templates makes applications vulnerable even if there was a completely secure sandbox:

  • https:/ in this blog post the author shows a (now closed) vulnerability in the Plunker application due to server-side rendering inside an Angular template.
  • https:/ in this blog post the author describes an attack, which does not rely upon an expression sandbox bypass, that can be made because the sample application is rendering a template on the server that contains user entered content.
    It’s best to design your application in such a way that users cannot change client-side templates.
  • Do not mix client and server templates
  • Do not use user input to generate templates dynamically
  • Do not run user input through $scope.$eval (or any of the other expression parsing functions listed above)
  • Consider using {@link ng.directive:ngCsp CSP} (but don’t rely only on CSP)
    You can use suitably sanitized server-side templating to dynamically generate CSS, URLs, etc, but not for generating templates that are bootstrapped/compiled by Angular.
    If you must continue to allow user-provided content in an Angular template then the safest option is to ensure that it is only present in the part of the template that is made inert via the {@link ngNonBindable} directive.

Reference: https:/

Version Affected



Root Cause

angular.1.8.2[1.3.3, )