CVE-2020-7791 Overview
CVE-2020-7791 is a Denial of Service vulnerability affecting the i18n internationalization package for ASP.NET applications. The vulnerability arises from insufficient handling of erroneous language tags in the src/i18n/Concrete/TextLocalizer.cs and src/i18n/LocalizedApplication.cs source files. When malformed or invalid language tags are processed, the application fails to properly validate input before use, leading to a NullReferenceException that can crash the application.
Critical Impact
Applications using vulnerable versions of the i18n package can be crashed remotely by attackers sending specially crafted language tags, causing service disruption for legitimate users.
Affected Products
- i18n_project i18n versions prior to 2.1.15
- ASP.NET applications using the vulnerable i18n library
Discovery Timeline
- December 11, 2020 - CVE-2020-7791 published to NVD
- November 21, 2024 - Last updated in NVD database
Technical Details for CVE-2020-7791
Vulnerability Analysis
This vulnerability is a classic input validation error that leads to a Denial of Service condition. The i18n library, designed to provide internationalization support for ASP.NET applications, failed to properly validate language tag inputs before processing them. When an attacker supplies a malformed or empty language tag, the application attempts to use this invalid input without first checking if it is set or valid, resulting in a NullReferenceException.
The vulnerability specifically impacts the TextLocalizer.cs and LocalizedApplication.cs components, which are responsible for handling language localization requests. Since these components process user-controllable input (language tags typically derived from HTTP headers or URL parameters), an external attacker can trigger the vulnerability remotely without authentication.
Root Cause
The root cause of CVE-2020-7791 is missing null and validity checks for language tag inputs in critical code paths. The TextLocalizer.cs file processed language tags without first verifying they were properly set using the IsSet() method. Similarly, LocalizedApplication.cs assigned DefaultLanguageTag from LanguageTag.GetCachedInstance() without checking if the returned value was null.
This insufficient input validation allowed malformed language tags to propagate through the application, eventually causing a NullReferenceException when the code attempted to access properties or methods on null objects.
Attack Vector
The attack vector for this vulnerability is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending HTTP requests with specially crafted or malformed Accept-Language headers or language parameters to an application using the vulnerable i18n package. When the application attempts to process these invalid language tags, it triggers a NullReferenceException, causing the request to fail and potentially crashing the application thread.
The following patch demonstrates the security fix applied to TextLocalizer.cs:
{
// Note that there is no need to serialize access to System.Web.HttpRuntime.Cache when just reading from it.
//
+ if (!langtag.IsSet()) {
+ return false; }
+
// Default language is always valid.
if (LocalizedApplication.Current.MessageKeyIsValueInDefaultLanguage
&& LocalizedApplication.Current.DefaultLanguageTag.Equals(langtag)) {
Source: GitHub Commit
The fix in LocalizedApplication.cs adds null checking before assignment:
}
set
{
- DefaultLanguageTag = LanguageTag.GetCachedInstance(value);
+ LanguageTag defaultLanguageTag = LanguageTag.GetCachedInstance(value);
+ if (defaultLanguageTag != null) {
+ DefaultLanguageTag = defaultLanguageTag; }
}
}
- public LanguageTag DefaultLanguageTag { get; set; }
+ public LanguageTag DefaultLanguageTag { get; private set; }
Source: GitHub Commit
Detection Methods for CVE-2020-7791
Indicators of Compromise
- Presence of NullReferenceException errors in application logs originating from TextLocalizer.cs or LocalizedApplication.cs
- Unusual patterns of HTTP requests with malformed or empty Accept-Language headers
- Application crashes or restarts correlated with localization-related request processing
- Increased error rates in ASP.NET applications using the i18n library
Detection Strategies
- Monitor application logs for NullReferenceException stack traces referencing i18n.Concrete.TextLocalizer or i18n.LocalizedApplication
- Implement Web Application Firewall (WAF) rules to detect and block requests with abnormal language tag patterns
- Use Software Composition Analysis (SCA) tools to identify i18n package versions prior to 2.1.15 in your dependencies
- Configure application performance monitoring to alert on elevated exception rates
Monitoring Recommendations
- Enable detailed exception logging for ASP.NET applications to capture full stack traces
- Set up alerts for sudden increases in application restarts or crash events
- Monitor HTTP request headers for anomalous Accept-Language values
- Track dependency versions across your application portfolio to identify vulnerable i18n installations
How to Mitigate CVE-2020-7791
Immediate Actions Required
- Upgrade the i18n package to version 2.1.15 or later immediately
- Review application logs for evidence of exploitation attempts
- Implement input validation for language tag parameters at the application boundary
- Consider implementing rate limiting on endpoints that process localization requests
Patch Information
The vulnerability has been addressed in i18n version 2.1.15. The fix adds proper null and validity checks before processing language tags. The patch commit c418e3345313dc896c1951d8c46ab0b9b12fcbd3 implements the IsSet() check in TextLocalizer.cs and adds null validation in LocalizedApplication.cs before assigning the DefaultLanguageTag property. Additionally, the DefaultLanguageTag property setter was changed to private set to prevent external modification.
For detailed patch information, refer to the GitHub Commit and the Snyk Vulnerability Report.
Workarounds
- Implement application-level input validation to sanitize language tags before they reach the i18n library
- Use try-catch blocks around localization calls to gracefully handle NullReferenceException errors
- Deploy a WAF rule to filter requests with malformed Accept-Language headers
- Consider implementing a default fallback language to avoid processing potentially malicious language tag inputs
# Example: Update i18n package via NuGet Package Manager Console
Update-Package i18n -Version 2.1.15
# Or via .NET CLI
dotnet add package i18n --version 2.1.15
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


