Table of Contents
- Understanding Template Injection
- How get_template_part is Abused
- Dynamic Template Loading Risks
- Input Validation and Sanitization
- Safe Template Architecture
- Real-World Exploitation Scenarios
- Testing and Audit Procedures
- FAQ
Understanding Template Injection
Template injection is a server-side vulnerability where an attacker controls portions of template code, allowing them to execute arbitrary code or access sensitive data. In WordPress themes, template injection occurs when user-controlled input is used to dynamically load or render template files without proper validation.
The vulnerability is particularly dangerous because WordPress themes have deep access to site data, user information, and configuration. A compromised template can read the WordPress database, modify site content, create backdoors, or exfiltrate sensitive data. Unlike front-end injection attacks, server-side template injection executes with the full permissions of the WordPress installation.
Template injection differs from typical code injection because the attacker doesn't inject raw PHP—they inject template file paths or expressions that the template engine then processes. In WordPress, this typically means injecting file paths that get_template_part(), include, or require will load.
A simple example: imagine a WordPress theme with a page template that loads a custom section based on a URL parameter:
<?php
$section = $_GET['section'];
get_template_part( 'sections/' . $section );
?>
If a user navigates to ?section=../wp-load, the code would attempt to load the sections/../wp-load.php file, which actually resolves to wp-load.php. This could expose sensitive data or cause unexpected behavior. More sophisticated attacks might use path traversal to load theme files containing sensitive information or code.
Template injection is a class of vulnerability that's particularly common in WordPress because:
- WordPress themes frequently use dynamic template loading for flexibility
- Developers often assume user input is relatively safe
- The attack surface includes URLs, form inputs, POST data, and stored database values
- WordPress doesn't enforce template security by default—it's developer responsibility
WP HealthKit's security audit capabilities identify themes with template injection vulnerabilities by analyzing how themes load templates and whether they properly validate input.
How get_template_part is Abused
The get_template_part() function is central to WordPress theme architecture. It allows themes to load template partial files, promoting code reuse and modularity. However, when used with unsanitized input, it creates template injection vulnerabilities.
The function's normal usage looks like this:
// Load the section-about.php partial from the theme
get_template_part( 'section', 'about' );
This is safe because the parameters are hardcoded. The theme controls exactly which template loads.
Problematic usage looks like this:
// Load a template based on user input
$template = $_GET['template'];
get_template_part( 'sections/' . $template );
Now the attacker can request ?template=testimonials to load sections/testimonials.php, which might be fine. But what if they request ?template=../../../wp-config? The function would attempt to load a file at path sections/../../../wp-config.php, which resolves to wp-config.php in the WordPress root. While wp-config.php doesn't have a .php extension in the parameter, the attacker could request ?template=../../../wp-config.php and the function would load that file, potentially exposing the database credentials if the file is accidentally readable.
More sophisticated attacks use path traversal to find sensitive theme files. A theme might have a file like includes/private-key.php containing API keys or secrets. An attacker discovering this file could access it through path traversal.
The attack becomes more dangerous when combined with other WordPress features. For example:
$template = isset( $_GET['view'] ) ? $_GET['view'] : 'default';
$template = preg_replace( '/[^a-z0-9_-]/', '', $template ); // Weak sanitization
get_template_part( 'templates/' . $template );
This sanitization removes special characters, but an attacker might still bypass it. If the theme has template files like templates/admin_panel.php or templates/backup_data.php, the attacker could load them directly.
In some cases, themes don't use get_template_part() but instead directly include template files:
$page = $_GET['page'];
include( TEMPLATEPATH . '/pages/' . $page . '.php' );
This is even more dangerous because include can load any PHP file and execute it. If the attacker controls the filename, they might load a plugin file, a theme file with embedded PHP, or even a file they've uploaded through another vulnerability.
Dynamic Template Loading Risks
While dynamic template loading enables flexible, modular WordPress themes, it introduces security risks that developers must actively mitigate. The fundamental risk is loss of control over which code executes.
When a theme hardcodes template names, it controls exactly which files load. The theme is static and predictable. Dynamic template loading sacrifices this control for flexibility. If that flexibility comes from user input, you're giving users power to select which files load, which code executes, and what data is accessible.
Path traversal is the most direct attack. By including ../ in the filename, an attacker navigates up the directory tree. A request for section=../../../../wp-content/plugins/plugin-name/sensitive-file.php could load files far outside the intended directory.
File inclusion from various sources creates risk. WordPress applications can receive user input through multiple paths:
- URL query parameters (
?template=xyz) - POST request bodies (form submissions)
- Cookie values
- Database stored values (if previously user-controlled)
- HTTP headers
- Custom API endpoints
Each input source requires independent validation because different sources might be processed differently.
Timing attacks and information disclosure occur when error messages reveal file paths. If a template doesn't exist, WordPress might show an error message including the attempted file path. An attacker can use this to map the filesystem and discover sensitive files.
Cascading vulnerabilities emerge when template injection combines with other flaws. For example:
- Template injection + stored XSS: Attacker injects template path through form, stored data loads template, template displays user input without sanitization
- Template injection + file upload: Attacker uploads PHP file, uses template injection to load it
- Template injection + SQL injection: Attacker loads template containing a SQL injection vulnerability
Input Validation and Sanitization
Preventing template injection requires validating all input used in template selection. There's no shortcut—you must carefully examine every place user input reaches template loading functions.
The most secure approach is whitelisting. Define an explicit list of allowed templates and only load from that list:
$allowed_templates = array(
'about' => 'about',
'services' => 'services',
'contact' => 'contact',
);
$template = isset( $_GET['template'] ) ? $_GET['template'] : 'default';
if ( array_key_exists( $template, $allowed_templates ) ) {
get_template_part( 'sections/' . $allowed_templates[ $template ] );
} else {
get_template_part( 'sections/default' );
}
This approach is bulletproof. The user can only load templates explicitly defined in your array. No path traversal, no discovery of unexpected files, no injection attacks. This is the recommended approach whenever feasible.
When whitelisting isn't practical (for example, when templates are dynamically created from plugin or theme additions), use strict pattern matching:
$template = isset( $_GET['template'] ) ? $_GET['template'] : 'default';
// Whitelist only alphanumeric, hyphen, and underscore
if ( ! preg_match( '/^[a-zA-Z0-9_-]+$/', $template ) ) {
wp_die( 'Invalid template name' );
}
get_template_part( 'sections/' . $template );
This rejects any input containing special characters that could be used for path traversal. The regex ^[a-zA-Z0-9_-]+$ only allows letters, numbers, hyphens, and underscores.
Avoid using basename() as a security measure, though it can be part of the solution:
// NOT SECURE - basename is not a security function
$template = basename( $_GET['template'] );
get_template_part( 'sections/' . $template );
basename() removes directory paths from a filename, but it's not designed as a security function and can be bypassed with null bytes or other tricks in older PHP versions.
Validate not just the template name, but the resolved path:
$template = isset( $_GET['template'] ) ? sanitize_file_name( $_GET['template'] ) : 'default';
// Resolve the actual path
$template_path = get_template_directory() . '/sections/' . $template . '.php';
$template_path = realpath( $template_path );
// Verify the resolved path is within the template directory
$template_dir = realpath( get_template_directory() );
if ( $template_path && strpos( $template_path, $template_dir ) === 0 ) {
include( $template_path );
} else {
wp_die( 'Invalid template' );
}
Using realpath() resolves all path traversal sequences (../, ./, etc.) to the actual file path, then you verify that path is within your expected directory. This prevents path traversal attacks completely.
For theme files loaded through require or include, use a safer alternative when possible. The load_template() function, though internal to WordPress, applies some security checks. Better yet, use get_template_part() which is designed for this purpose and receives more security scrutiny.
Safe Template Architecture
Beyond input validation, designing templates carefully reduces injection risk. Architecture decisions made when designing the theme affect how securely it operates.
Centralize template loading through helper functions:
// Safe template loading helper
function my_theme_load_template( $template_base, $template_name = '' ) {
// Validate template names against whitelist or pattern
if ( ! preg_match( '/^[a-zA-Z0-9_-]+$/', $template_base ) ) {
wp_die( 'Invalid template base' );
}
if ( $template_name && ! preg_match( '/^[a-zA-Z0-9_-]+$/', $template_name ) ) {
wp_die( 'Invalid template name' );
}
get_template_part( $template_base, $template_name );
}
// Use the helper throughout the theme
my_theme_load_template( 'sections', 'about' );
By centralizing template loading, you audit the validation once rather than in multiple places. This reduces the chance of missing a vulnerable call.
Never trust stored data. Even if data comes from the WordPress database rather than directly from user input, validate it before using it in template selection. A plugin or user profile field might be modified through a different attack vector, and then your template loading becomes vulnerable.
Use get_query_var() carefully. The WordPress query parser extracts URL components into variables that can be accessed with get_query_var(). These variables are safer than raw $_GET because they're processed through WordPress's URL handling, but they're not automatically sanitized. Validate them before using in template names:
$view = get_query_var( 'view' );
if ( $view && preg_match( '/^[a-zA-Z0-9_-]+$/', $view ) ) {
get_template_part( 'sections/' . $view );
}
Document template usage. If template loading is conditional, document what conditions trigger which templates. This helps developers spot unexpected template loading patterns during code review.
Register custom template directories explicitly:
// Register a custom template directory
add_filter( 'theme_file_tree', function( $paths ) {
return array_merge( $paths, array(
get_template_directory() . '/custom-templates',
) );
} );
This gives themes more control over where templates are loaded from, reducing the attack surface.
Real-World Exploitation Scenarios
Understanding how attackers exploit template injection helps developers recognize vulnerabilities in their code.
Scenario 1: Portfolio theme with project selection. A WordPress portfolio theme loads different project templates based on URL parameters:
$project = $_GET['project'];
get_template_part( 'projects/' . $project );
An attacker discovers that the theme has a settings-panel template (intended to be only loaded by admins). They navigate to ?project=settings-panel and can view the settings panel output, potentially revealing configuration details.
Scenario 2: Blog theme with layout selection. A blog theme allows users to select different layouts for archives:
$layout = isset( $_GET['layout'] ) ? $_GET['layout'] : 'grid';
get_template_part( 'layouts/' . $layout );
The attacker requests ?layout=../../../wp-config.php hoping to load the config file. While PHP files without the .php extension won't execute, if the file is readable, it might output content. More dangerously, if the site runs a plugin that processes all included files, the attacker might trigger code.
Scenario 3: E-commerce theme with dynamic payment options. The theme loads different payment methods dynamically:
$payment = $_POST['payment_method'];
include( TEMPLATEPATH . '/checkout/' . $payment . '.php' );
An attacker discovers that the theme has a template file at includes/gateway-credentials.php containing API keys. They post payment_method=../includes/gateway-credentials and load the file, accessing credentials.
Scenario 4: Multi-site WordPress with template selection per-site. A WordPress multisite setup allows each site to select its layout template:
$layout = get_option( 'site_layout' );
get_template_part( 'layouts/' . $layout );
The setting is admin-controlled, but an older version of a site admin plugin has a vulnerability allowing SQL injection. An attacker exploits that vulnerability to modify the site option to load an unintended template, or potentially to include a path traversal attack.
Testing and Audit Procedures
Finding template injection vulnerabilities requires examining theme code and testing how templates are loaded.
Code review focuses on template loading functions. Search the theme code for:
get_template_part(calls with variable parametersinclude(orrequire(statements with file paths including variablesload_template(with variable paths
For each instance, verify that the variable input is validated before use. Validation should be explicit and obvious—if you have to debate whether it's safe, it probably isn't.
Static analysis tools can help. The PHPCS WordPress standard includes rules for detecting insecure include statements. Running:
phpcs --standard=WordPress /path/to/theme
Will flag potentially problematic patterns.
Dynamic testing involves actually attempting template injection. Tools like WP HealthKit scan themes for template injection vulnerabilities by:
- Identifying template loading patterns
- Analyzing input validation
- Simulating injection attempts to see if validation can be bypassed
- Checking resolved file paths for directory traversal
Manual testing can be done by requesting suspicious URLs:
?template=../../wp-config?template=../plugin-name/file?section=admin?page=../../../etc/passwd
If these requests load unexpected files or produce error messages revealing file paths, you've found a vulnerability.
Use a web application firewall (WAF) to monitor for template injection attempts:
# Nginx WAF rule example
location / {
if ($args ~* "\.\.\/|\.\.\\") {
return 403;
}
}
This blocks requests containing path traversal sequences, though determined attackers might find bypasses.
FAQ
Is using get_template_part() with variables always unsafe?
No. Using variables with get_template_part() is safe if the variable is properly validated. If you validate that the variable matches a strict whitelist or pattern, it's secure. The vulnerability comes from using variables without validation, not from using variables themselves.
Can I use basename() to prevent path traversal?
Not reliably. While basename() removes directory components, it's not designed as a security function. In older PHP versions, null bytes could bypass it. It's better to use realpath() to resolve paths and verify the resolved path is within an expected directory.
What about WordPress nonces? Do they prevent template injection?
Nonces protect against CSRF attacks, not template injection. A nonce proves that a request came from your own site, but doesn't validate the content of the request. A nonce doesn't prevent path traversal attacks in template loading.
How can I test if my theme is vulnerable to template injection?
Review the code for template loading with unsanitized variables. Attempt to load unintended templates by requesting URLs with path traversal sequences. Use static analysis tools or WP HealthKit to scan for patterns. If templates load that you didn't expect, you've found a vulnerability.
Are child themes more secure than parent themes?
Not inherently. Both can have template injection vulnerabilities. A child theme might be more secure if it overrides vulnerable code in the parent, but it could also introduce new vulnerabilities. Review the code carefully regardless of whether it's a parent or child theme.
Can I use WordPress capabilities checks instead of input validation?
Not as a replacement. Capability checks verify that a user has permission to perform an action, but they don't prevent template injection. You should use both: validate template names AND verify that the user has permission to load that template.
Additional Resources
For a comprehensive view of how WP HealthKit approaches plugin analysis, explore our 62 verification layers or browse the plugin directory to see real audit scores. Ready to check your own plugin? Run a free audit now.
Frequently Asked Questions
How does WP HealthKit detect security vulnerabilities automatically?
WP HealthKit uses 62 verification layers including static analysis, pattern matching, and dependency scanning to identify vulnerabilities in WordPress plugins. The automated scanning catches issues that manual code review would miss, providing comprehensive security coverage across your entire codebase.
What are the most common WordPress plugin security vulnerabilities?
The most frequently discovered vulnerabilities include cross-site scripting through improper output escaping, SQL injection via unparameterized queries, cross-site request forgery from missing nonce verification, and privilege escalation through inadequate capability checks. These four categories account for over seventy percent of all reported plugin vulnerabilities.
How often should I audit my WordPress plugin for security issues?
Security audits should happen at every major release, after significant code changes, and on a regular quarterly schedule. Automated scanning through CI/CD pipelines provides continuous monitoring, while thorough manual reviews should complement automated testing at least twice per year.
Can automated tools replace manual security code review?
Automated tools like WP HealthKit catch the majority of common vulnerability patterns quickly and consistently, but they complement rather than replace manual review. Complex business logic vulnerabilities, architectural issues, and novel attack vectors still benefit from expert human analysis. The ideal approach combines both.
What should I do if a vulnerability is discovered in my plugin?
Follow responsible disclosure practices: verify the vulnerability, develop and test a fix, notify affected users through your update channel, and publish a security advisory. Coordinate with the WordPress security team if the vulnerability is severe. Speed matters — most attackers begin exploitation within days of public disclosure.
Conclusion
Template injection is a dangerous vulnerability in WordPress themes because themes have deep system access. By using unsanitized user input in template loading, developers give attackers control over which code executes and which files are accessed.
Preventing template injection requires careful input validation using whitelisting or strict pattern matching, resolving paths to verify they're within expected directories, and centralizing template loading through validated helper functions. By treating all user input as untrusted—including URL parameters, POST data, and stored values—theme developers can build secure, flexible template systems.
WP HealthKit's security auditing identifies template injection vulnerabilities in your WordPress installation. The platform analyzes themes and plugins for insecure template loading patterns and helps you remediate vulnerabilities before attackers exploit them.
Audit your WordPress themes for template injection vulnerabilities with WP HealthKit and ensure your site's code execution is secure.