CVE-2026-8760: Path traversal in CGI::Application load_tmpl()

Affected versions and exposure conditions

The verified affected product is CGI::Application, and the affected version range is < 4.70. The fixed version is 4.70. Upstream states that the fix in 4.70 changes load_tmpl() so it checks every path segment and rejects paths that attempt to escape the allowed template root. The referenced patch commit is 3e594f4d0f7f5617f8e01c6435cc5ec8f8f92774, titled “Sanitize relative template path and return undef if invalid”.

That version boundary matters operationally. If your application depends on CGI::Application 4.69 or any earlier release, you should consider it vulnerable until proven otherwise. If you are on 4.70, the specific traversal described in the advisory should be addressed by upstream. If you do not know which version is installed, treat that as an incident-response style inventory gap and verify it immediately rather than assuming your package manager or Perl environment is current.

Exposure also depends on application behavior. An app is especially at risk if it does any of the following:

By contrast, applications that only use hard-coded template names and never derive them from user input may still have the vulnerable library installed, but the exploit path may not be reachable in normal operation. That distinction is important for prioritization, but it should not be used as a reason to defer patching. Library-level fixes are available, and removing vulnerable code paths reduces long-term risk.

CVSS breakdown and exploitation status

The CVSS v3.1 base score is 6.5 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. This translates to a network-reachable issue with low attack complexity, no privileges required, and high confidentiality impact. The presence of UI:R means some form of user interaction is required in the scoring model. In practice, defenders should interpret that carefully: the exact interaction requirement depends on application design and request handling. The primary sources do not provide a more granular exploit chain beyond user-controlled input reaching load_tmpl().

The most important exploitation fact is this: there is no verified evidence from the provided primary sources that exploitation in the wild has been confirmed. The CVE is not listed in CISA KEV, so there is no CISA confirmation of active exploitation and no KEV remediation deadline. That reduces urgency relative to actively exploited perimeter bugs, but it does not make the issue low-priority for exposed or internet-facing legacy applications.

On proof-of-concept status, no standalone public PoC repository is verified in the supplied sources. However, there is public technical detail in the GitHub advisory, public issue discussion, and the upstream patch. That means defenders should assume the bug is reproducible by anyone comfortable reading a Perl patch diff and testing path traversal conditions. In short:

If a fact is unknown, defenders should assume reasonable attacker capability. Here, that means assuming the bug can likely be reproduced internally or by a capable adversary even without a polished public exploit repository.

What defenders should do next

First, identify whether you actually use CGI::Application and which version is deployed. Perl environments are often fragmented across system packages, local library paths, CPAN installations, containers, and application bundles. Do not rely on a single inventory source. Check deployed hosts, build pipelines, and application manifests. If you find CGI::Application before 4.70, prioritize systems that are internet-facing or handle untrusted input.

Second, audit code for any path where request data, cookies, query parameters, form values, headers, or user profile settings can influence load_tmpl() arguments. The advisory explicitly warns against passing user-controlled input into load_tmpl(). Even if you cannot upgrade immediately, this code audit tells you whether the vulnerable functionality is practically reachable. A short-term reduction in risk is to replace dynamic template selection with a fixed allowlist.

Third, assess blast radius. Because this is an arbitrary file-read style issue, the severity in your environment depends heavily on what files the application user can read. Review file permissions, local secrets, config files, database credentials, API tokens, and any templates or content outside the expected root that could be exposed. If the web process can read broad portions of the filesystem, the confidentiality impact may exceed what teams informally expect from a “template bug.”

Technical Notes: version discovery and code audit

Use simple Perl one-liners to identify the installed module version:

perl -MCGI::Application -e 'print $CGI::Application::VERSION, "\n";'

If you manage dependencies with CPAN tooling, verify package state:

cpanm --info CGI::Application
cpan -D CGI::Application

Search application code for risky usage patterns:

grep -R "load_tmpl" /var/www /opt/apps 2>/dev/null
grep -R "param(.*tmpl\|template\|view" /var/www /opt/apps 2>/dev/null

A high-risk example to flag in review:

my $template = $self->query->param('template');
my $t = $self->load_tmpl($template);

A safer pattern uses an explicit allowlist:

my %allowed = (
  home  => 'home.tmpl',
  about => 'about.tmpl',
  help  => 'help.tmpl',
);

my $key = $self->query->param('template') // 'home';
my $file = $allowed{$key} || 'home.tmpl';
my $t = $self->load_tmpl($file);

Technical deep dive

The root cause is a path validation failure in load_tmpl(). According to the GitHub advisory, validation is skipped entirely if the filename argument starts with .., due to the use of splitpath() from File::Spec::Unix. That is a classic normalization and validation pitfall: if path handling is inconsistent across edge cases, attackers can supply relative traversal segments that bypass intended root confinement.

The fix released in 4.70 changes that behavior by sanitizing each path component and rejecting traversal attempts that would escape the allowed template root. That design choice is important. Secure path handling cannot rely on checking only prefixes or assuming path parsing functions behave safely in every case. Segment-by-segment validation is the right control for relative traversal problems, especially in frameworks that expose template-loading helpers to application code.

For defenders, the real lesson is broader than this single CVE. Any legacy framework helper that accepts filenames, template names, include paths, or local resource identifiers should be reviewed with the same question: can user input reach it directly or indirectly? In older Perl applications, the answer is often “yes, through convenience code written years ago.” CVE-2026-8760 is therefore both a patching issue and an application review trigger.

Technical Notes: vulnerable vs safer usage

Illustrative vulnerable pattern:

sub show_page {
    my $self = shift;
    my $page = $self->query->param('page');
    my $tmpl = $self->load_tmpl($page);
    print $self->header;
    print $tmpl->output;
}

Safer pattern after remediation:

sub show_page {
    my $self = shift;

    my %pages = (
        home  => 'home.tmpl',
        about => 'about.tmpl',
        faq   => 'faq.tmpl',
    );

    my $page = $self->query->param('page') // 'home';
    my $file = $pages{$page} or die "invalid page";

    my $tmpl = $self->load_tmpl($file)
      or die "template load failed";

    print $self->header;
    print $tmpl->output;
}

Additional Resources

For further reading on supply chain security, check out our glossary on supply chain security basics and learn more about the difference between EDR and antivirus in our FAQ.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.