Security Hardening

Four things reach the engine from outside the code of the service, and each is a different kind of input.

The rest of the page takes the surfaces in the order of how much damage each can do.

The table summarizes what the official change log says about security-relevant changes. It is the only source for the version numbers; the release dates are the ones printed there, which can precede the publication on Maven Central: 7.0.8 is dated 2026-07-07 in the change log, and its artifacts were published on Maven Central on 2026-08-05.

The configuration reference gives the query executer and $P!{} switches as Since: 7.0.7, while the change log lists them under 7.0.8. The two sources disagree by one release, and this page does not try to settle it. A service that depends on those switches should be on 7.0.8 or later, where both sources agree they exist, and should confirm the behavior with a test like the ones below, because a property the engine does not know is silently ignored.

Both entries describe a Java deserialization vulnerability in the Jaspersoft library that can lead to remote code execution. The details below are what the National Vulnerability Database (NVD) record showed on the baseline date.

For CVE-2026-6009 the NVD entry did not list affected versions at the time of checking, so the only version statement available is the fix version in the change log. The change log describes both fixes in the same words (a deserialization class filter), and the public records do not say what the second fix covers beyond the first. This page therefore does not describe the exploit paths of either CVE. The practical conclusion is the same for both and does not depend on the details: run 7.0.8 or later, keep the deserialization filter enabled, and never deserialize files that came from outside the trust boundary.

Because these records change, check the two entries in NVD again before relying on this table, and use the official JasperReports change log as the authority on which release contains which fix.

A JRXML file contains expressions such as $F{amount} or "Total: " + $V{total}. During compilation the engine turns each expression into a Java class, and with the default settings nothing restricts which classes the expression may use. To confirm it, the following template was compiled and filled with default settings. Its only element prints the value of an ordinary JVM system property; it could just as well have called Runtime, opened a socket or read a file.

Filling it with default settings printed the value of the property. That is the intended behavior of the library, not a defect: expressions are a programming language. The consequence is a rule with no exceptions in this section: a template that a user can write or modify is a program that the user can run on your server. Everything else on this page reduces the blast radius; none of it makes it safe to fill templates written by strangers on a shared JVM.

The same applies to scriptlets and extensions (see Scriptlets & Extensions), whose class names come from the template and which are loaded by the engine, and to the language attribute, which selects the expression compiler. Report authors should be treated as developers of the service, with review, version control and a build pipeline, not as end users.

A .jasper file, a .jrprint file and the streams that JRLoader reads are Java serialized object graphs. Since 7.0.4 the engine filters the classes that may appear in such a stream, and the filter is controlled by:

All of these are described as "Since 7.0.4" in the configuration reference except the value whitelist, whose version this page did not check. To see the filter work, a harmless AtomicInteger and a compiled JasperReport were each serialized and read back with JRLoader.loadObject. The first was refused with Class java.util.concurrent.atomic.AtomicInteger is not visible to deserialization, and the second loaded normally. Nothing malicious was used in this check, and no attempt was made to reproduce the exploit of either CVE.

The filter is a safety net for the classes that may appear in a stream, not a promise that a .jasper file from an unknown source is harmless: a compiled template contains the compiled expressions, so loading one and filling it is as dangerous as filling its source. The rule that follows is simple. Compile the templates of the service during the build, package the result, and load only those. Do not accept .jasper or .jrprint uploads, do not read them from a shared directory that other tenants can write, and do not keep serialized reports in a cache that untrusted code can write to.

A template refers to images, subreports, styles and fonts by location, and the engine resolves a location through repository services. The default repository service tries the file system, URLs and the classpath. That is convenient and also the path by which a template (or a parameter that feeds a location expression) can make the server read a local file or call a remote address.

Three switches limit it.

The configuration reference does not describe the syntax of the URL whitelist values, so the following behaviors were observed by running RepositoryUtil.getBytesFromLocation against 7.0.8, and should be re-checked after an upgrade.

So the two settings are complementary. Disable the file repository so that plain paths cannot be read, and turn on the URL filter so that only the hosts you control can be fetched. Better still, do not build resource locations from request data at all.

In a query, $P{customer} becomes a JDBC placeholder and the value is bound by the driver, while $P!{customer} is pasted into the query text. The second form exists for things a placeholder cannot express, such as a column list or an ORDER BY, and it is an SQL injection vector whenever the value is not a constant chosen by the code. The two templates below differ in one expression, and they were run against an invoice table with two rows (INV-1 for Ada and INV-2 for Grace) and the payload x' OR '1'='1.

The unsafe variant, invoices-unsafe.jrxml, has name="invoicesUnsafe" and the query SELECT number, customer FROM invoice WHERE customer = '$P!{customer}'; everything else is the same. The observed results:

The property that produces the failure is net.sf.jasperreports.query.parameter.clause.enabled. It defaults to true and, when false, any use of the $P!{} syntax in a query results in an error. Set it to false in every service that does not need dynamic query text. A service that does need it (for example to choose the sort column) should map a small set of constants in the Java code and pass the chosen constant as the parameter value, never a request value. The same page that describes the clause is Expressions, Parameters, Fields & Variables. Whether the clause is also reachable through other parameter syntaxes was not examined here.

PDF is the subject of this section, but a service that also exports HTML (for example for an in-browser preview of an invoice) copies hyperlink targets from the template and its parameters into href attributes. If the target comes from data, that is a way to publish an attacker’s link on your pages. Since 7.0.8 the HTML exporter can enforce a whitelist:

The template used for the check is the smallest possible link. Note the attribute linkType: an attribute spelled hyperlinkType, as in older JRXML, compiles without an error and produces no link at all, which would make the test pass for the wrong reason (see Hyperlinks, Bookmarks & Report Books).

Exporting it to HTML without the filter produced an a element pointing to the example address. With the filter on and the single allowed pattern https://docs\.bookshelf\.example/.*, the export failed with HTML export href URL "https://evil.example/phish" is not allowed. The property is described only for the HTML exporter. This page did not test whether the PDF exporter honors it, and it should not be assumed to.

Two further settings concern parsers inside the library.

Neither was exercised by an attack here; they are listed because the official reference calls out their purpose.

The settings are read from jasperreports.properties at the root of the classpath, which for a Spring Boot service means src/main/resources/jasperreports.properties. The same keys can also be set in code with DefaultJasperReportsContext.getInstance().setProperty(key, value), which is how the checks above were done. Which of the two is simpler depends on whether you want the settings reviewable as a file; the engine reads both.

A properties file needs the backslash of a regular expression doubled, which is why the dots are written \\.. Placed on the classpath, this file was picked up by a fresh JVM, and the invoices template from above still filled correctly with it. The four failures reported earlier (an expression that uses System, a $P!{} query, a read of a local file path and an HTML link to an address outside the whitelist) were reproduced with the same file. The whitelist for expressions must grow with your templates: the example allows only basic value types and the engine packages, and any report that formats dates with java.time or calls a helper class of the application fails until the class is added, which is the intended effect.

The jasperreports-jdt artifact used to compile expressions at run time pulls a Java compiler into the service. A service that compiles at build time and ships only .jasper files does not need a compiler at run time and has less to defend. Compiling at build time is one of the three options that JasperReports Architecture & Lifecycle compares (its examples compile at start-up instead), and the build setup with jasperreports-maven-plugin is in Large Reports & Performance.

The strongest control is architectural: the user chooses a report by a key and supplies parameter values, and never supplies the template, a path, a class name or a query. The class below is the whole policy in code. It compiles the templates that ship inside the application once, at start-up, and refuses any key it does not know. It was compiled and run: an unknown key such as a path-traversal string threw IllegalArgumentException, and a known key filled normally.

Two details of the engine matter when calling it. The parameters argument must be a mutable map: an immutable Map.of is rejected by the engine because it adds the built-in parameters to the map you pass, and the run of the class above confirmed an UnsupportedOperationException for it. Wrap request values in a new HashMap<>(...), as the engine expects. And a Java record cannot serve as a bean for JRBeanCollectionDataSource, which is a data source issue rather than a security one but a reason to prefer plain classes with getters for report rows.

The Maven dependencies are the ones of the first example on the data sources page; for the check on this page the only addition was H2 (com.h2database:h2:2.4.240) for the database.

The official sources behind the configuration examples are the configuration reference and the JasperReports change log.

A template review checklist, for the cases where authors who are not developers must contribute templates:

If the product truly needs end users to design reports, run the fill in a separate, disposable process or container with no credentials, a read-only file system, no outbound network, and CPU, memory and time limits, and treat its output as untrusted. The settings of this page reduce risk in that setup; they do not turn the in-process model into a sandbox.

For the account and request side of a Spring Boot service (authenticating who may request which report, and limiting what they can pass), see Spring Security and the REST integration in JasperReports Spring Boot Integration.