← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-7312 · CWE-522 · Disclosed 2026-06-02

CWE‑522: Insufficiently Protected Credentials in web services in Progress Sitefinity version from 14

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a spare key left under a flowerpot, but only at houses that installed the matching side door

CVE-2026-7312 is a plaintext credential exposure in Progress Sitefinity web services affecting the 14.0 through 15.4 trains: 14.0.7700 through 14.4.8151, 15.0.8200 through 15.0.8233, 15.1.8300 through 15.1.8334, 15.2.8400 through 15.2.8440, 15.3.8500 through 15.3.8530, and 15.4.8600 through 15.4.8629 based on the vendor's May 2026 fixed package builds. An unauthenticated remote attacker can obtain credentials or access keys used to connect the CMS to Sitefinity Insight, but the vendor also states exploitation requires active Insight integration and a non-default site configuration.

Progress scored this a 10.0 CRITICAL, which is technically understandable from the raw CVSS vector, but it overstates broad enterprise risk. The decisive friction is that this is not a universal pre-auth takeover of every Sitefinity site; it is a config-gated credential leak tied to a specific connected service, so the reachable population is much smaller than the full installed base and the blast radius is typically the linked Insight tenant rather than direct CMS code execution.

"Pre-auth is scary, but this only bites the slice of Sitefinity estates using Insight with a non-default setup."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a reachable vulnerable Sitefinity web service

An attacker uses curl, Burp Suite, or a simple HTTP scanner to probe known Sitefinity service routes and fingerprint a target running a vulnerable 14.0-15.4 build. This step only matters if the deployment both exposes the relevant web service path and has the vulnerable integration behavior enabled.
Conditions required:
  • Internet-reachable Sitefinity instance
  • Version in an affected 14.0-15.4 build range
  • Relevant Sitefinity web service route reachable from the attacker
Where this breaks in practice:
  • Many enterprises do not expose all Sitefinity service routes directly to the internet
  • Reverse proxies, Cloudflare, or WAF rules can block probing
  • Version fingerprinting is often noisy and not deterministic from banners alone
Detection/coverage: Basic vulnerability scanners will flag version ranges poorly unless they also validate the specific service behavior. Web logs should still show unusual requests to Sitefinity/Services or adjacent REST routes.
STEP 02

Trigger the credential disclosure path

Using Burp Repeater, Invoke-WebRequest, or raw HTTP requests, the attacker hits the vulnerable web service and extracts plaintext credentials or an access key used for the Sitefinity Insight connection. The vulnerability is unauthenticated, but the vendor states it requires non-default site configuration, which is the main real-world brake.
Conditions required:
  • Active Sitefinity Insight integration is configured
  • Non-default site configuration that exposes the vulnerable behavior
  • No upstream control blocks the request
Where this breaks in practice:
  • Estates without Insight enabled are not exploitable for this CVE
  • Default deployments may not expose the vulnerable condition
  • Some orgs isolate management/API paths with IP ACLs or VPN-only access
Detection/coverage: Signature coverage is likely immature on disclosure day. WAFs may catch abnormal parameter patterns, but this is better detected by reviewing access to the specific service endpoint plus any response bodies containing connector metadata.
STEP 03

Exchange the stolen key for Insight API access

Once the attacker has the leaked Insight access key, they can use the documented Sitefinity Insight API flow to request a short-lived bearer token from the Insight API. This is a clean, vendor-supported workflow, so post-theft activity can look like legitimate integration traffic unless you watch source IPs and token issuance patterns.
Conditions required:
  • Valid leaked Insight access key
  • Outbound internet access to the Insight API
  • Insight tenant still trusts the key and it has not been rotated
Where this breaks in practice:
  • This does not automatically yield local OS or IIS execution on the CMS server
  • Key scope is tied to the Insight tenant and connector permissions
  • Defenders can break the chain quickly by rotating the key
Detection/coverage: Monitor Insight-side token issuance and API use from unfamiliar IPs, geographies, or user agents. This is where defenders have the clearest high-signal detection point.
STEP 04

Access or manipulate connected Insight data

With the token, the attacker can query or submit data through Insight endpoints, potentially exposing customer interaction data, contact properties, and analytics metadata depending on tenant permissions and enabled features. Impact can be serious for privacy and analytics integrity, but it is still typically connected-service compromise, not instant full CMS or domain compromise.
Conditions required:
  • Leaked key is valid and authorized for useful Insight operations
  • Target uses Insight features holding data of value
  • Tenant permissions allow the requested API actions
Where this breaks in practice:
  • Some tenants will expose more analytics than sensitive PII
  • Permission boundaries inside Insight may limit what the stolen key can do
  • Blast radius is often narrower than raw CVSS suggests
Detection/coverage: Review Insight API calls for unusual volume, data-center paths, token exchange events, and access to contact or content-data endpoints outside normal integration schedules.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public active exploitation evidence found in the sources reviewed as of 2026-06-02; not in CISA KEV.
Public PoC availabilityNo public PoC located in reviewed GitHub, Vulners, or public advisory aggregators on disclosure day.
EPSSNo public EPSS value surfaced in the reviewed sources at the time of assessment, likely because the CVE was disclosed on 2026-06-02 and enrichment is still catching up.
KEV statusAbsent from CISA KEV when checked against the catalog on 2026-06-02.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N says pre-auth remote with high confidentiality and integrity impact, but the vendor's own description adds two major gates: active Insight integration and non-default configuration.
Affected versions14.0.7700 through 14.4.8151; 15.0.8200 through 15.0.8233; 15.1.8300 through 15.1.8334; 15.2.8400 through 15.2.8440; 15.3.8500 through 15.3.8530; 15.4.8600 through 15.4.8629.
Fixed versionsVendor package feeds show new builds published 2026-05-11: 14.4.8152, 15.0.8234, 15.1.8335, 15.2.8441, 15.3.8531, 15.4.8630.
Exposure populationSitefinity is enterprise-relevant but not mass-market huge; WhatCMS reports roughly 18,554 detected websites. The exploitable slice is smaller still because this CVE requires both Insight integration and non-default configuration.
DisclosurePublished by Progress Software Corporation on 2026-06-02; NVD is still undergoing enrichment.
Researcher / reporting sourceThe public CVE/NVD record currently attributes the record to Progress Software Corporation; no external researcher credit was visible in reviewed public sources.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.9/10)

The single biggest reason this is HIGH instead of CRITICAL is that exploitation requires active Sitefinity Insight integration plus a non-default configuration, which sharply narrows the reachable population. It is still serious because the bug is pre-auth remote and yields reusable credentials for a connected service, but this is not a universal internet-to-CMS compromise across all Sitefinity installs.

HIGH Vendor-described prerequisites materially reduce exposed population
MEDIUM Downstream blast radius after Insight key theft

Why this verdict

  • Downgrade for deployment friction: the vendor explicitly says exploitation needs active Insight integration and non-default site configuration, so this is not reachable on the average Sitefinity deployment.
  • Still pre-auth remote: no credentials, no user interaction, and network reachability are enough once the config exists, which keeps this well above MEDIUM.
  • Blast radius is connected-service centric: the likely impact is compromise of Sitefinity Insight access and data, not guaranteed IIS/OS execution or instant CMS administrator control, so the vendor's 10.0 is too hot for prioritization at enterprise scale.

Why not higher?

A higher rating would require either broad default exposure across most Sitefinity estates or evidence that the leaked credentials reliably convert into full CMS or server compromise. The public record instead says this needs a niche configuration and targets Insight credentials, which is materially narrower than a generic pre-auth RCE or auth bypass on the CMS itself.

Why not lower?

A lower rating would ignore the fact that this is unauthenticated remote credential theft on an externally reachable web service. In environments that do use Insight, stolen access keys can be exchanged for valid API tokens and may expose customer interaction data or enable manipulation of analytics data, which is too consequential for a LOW or MEDIUM call.

05 · Compensating Control

What to do — in priority order.

  1. Restrict the vulnerable service path — Put the affected Sitefinity service routes behind IP allowlists, VPN, reverse-proxy access policy, or WAF path restrictions within 30 days. This directly attacks the only pre-auth part of the chain: internet reachability to the disclosure endpoint.
  2. Disable unused Insight integration — If a site does not actively need Sitefinity Insight, disable or remove the connector within 30 days. This is the cleanest compensating control because the CVE is not exploitable without active Insight integration.
  3. Rotate Insight access keys — Generate new Sitefinity Insight access keys and retire old ones within 30 days, especially on internet-facing instances. Even if a key was already exposed, rotation breaks the post-theft token issuance step.
  4. Monitor Insight token issuance — Instrument Insight API usage and alert on bearer-token issuance or data access from unfamiliar IPs, user agents, or geographies within 30 days. The token-exchange step is one of the best defender choke points in this attack chain.
  5. Review non-default service configuration — Audit the Sitefinity configuration delta from default, especially custom web-service exposure, integration endpoints, and connector settings within 30 days. The vendor's own description says the vulnerable state is configuration-dependent, so configuration review is not optional here.
What doesn't work
  • Changing ordinary CMS user passwords alone does not fix this, because the exposed secret is tied to the Sitefinity Insight connection, not necessarily an interactive CMS account.
  • Hiding the Sitefinity login page does not help; the attack path is through web services and does not require backend authentication.
  • EDR on the Windows host is not the primary control here because the critical steps are HTTP request/response abuse and downstream SaaS API use, not obvious malware execution on the server.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows IIS host or on a mounted copy of the Sitefinity web root. Invoke it as powershell.exe -ExecutionPolicy Bypass -File .\check-cve-2026-7312.ps1 -WebRoot 'C:\inetpub\wwwroot\SitefinityWebApp'. Read access to the web root is usually enough; local admin is not required unless your app folder ACLs are locked down.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-cve-2026-7312.ps1

# Verifies likely exposure to CVE-2026-7312 on a Sitefinity web root.

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


param(
    [Parameter(Mandatory=$true)]
    [string]$WebRoot
)

$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$Status,
        [string]$Message,
        [int]$Code
    )
    Write-Output ("{0}: {1}" -f $Status, $Message)
    exit $Code
}

function Parse-Version {
    param([string]$s)
    try { return [version]$s } catch { return $null }
}

function In-Range {
    param(
        [version]$v,
        [version]$min,
        [version]$maxExclusive
    )
    return ($v -ge $min -and $v -lt $maxExclusive)
}

if (-not (Test-Path -LiteralPath $WebRoot)) {
    Write-Result -Status 'UNKNOWN' -Message "Web root not found: $WebRoot" -Code 2
}

# Sitefinity projects are statically compiled and keep references in the bin folder.

# We use Telerik.Sitefinity.dll file version as the runtime Sitefinity version signal.

$dll = Get-ChildItem -LiteralPath $WebRoot -Recurse -File -Filter 'Telerik.Sitefinity.dll' |
       Sort-Object FullName |
       Select-Object -First 1

if (-not $dll) {
    Write-Result -Status 'UNKNOWN' -Message 'Telerik.Sitefinity.dll not found under the supplied web root.' -Code 2
}

$fileVersion = $dll.VersionInfo.FileVersion
if (-not $fileVersion) {
    Write-Result -Status 'UNKNOWN' -Message "Could not read file version from $($dll.FullName)" -Code 2
}

$v = Parse-Version $fileVersion
if (-not $v) {
    Write-Result -Status 'UNKNOWN' -Message "Unparseable Sitefinity version: $fileVersion" -Code 2
}

# Fixed builds inferred from Progress May 2026 package releases.

$affected = $false
$branch = $null

if (In-Range -v $v -min ([version]'14.0.7700.0') -maxExclusive ([version]'14.4.8152.0')) { $affected = $true; $branch = '14.0-14.4' }
elseif (In-Range -v $v -min ([version]'15.0.8200.0') -maxExclusive ([version]'15.0.8234.0')) { $affected = $true; $branch = '15.0' }
elseif (In-Range -v $v -min ([version]'15.1.8300.0') -maxExclusive ([version]'15.1.8335.0')) { $affected = $true; $branch = '15.1' }
elseif (In-Range -v $v -min ([version]'15.2.8400.0') -maxExclusive ([version]'15.2.8441.0')) { $affected = $true; $branch = '15.2' }
elseif (In-Range -v $v -min ([version]'15.3.8500.0') -maxExclusive ([version]'15.3.8531.0')) { $affected = $true; $branch = '15.3' }
elseif (In-Range -v $v -min ([version]'15.4.8600.0') -maxExclusive ([version]'15.4.8630.0')) { $affected = $true; $branch = '15.4' }

if (-not $affected) {
    Write-Result -Status 'PATCHED' -Message "Sitefinity version $fileVersion is outside the known vulnerable ranges for CVE-2026-7312." -Code 0
}

# Check for signs of active Insight integration. This CVE requires Insight + non-default config.

$insightDll = Get-ChildItem -LiteralPath $WebRoot -Recurse -File -ErrorAction SilentlyContinue |
              Where-Object { $_.Name -match 'DigitalExperienceCloudConnector|Insight' } |
              Select-Object -First 5

$configHits = @()
$configFiles = Get-ChildItem -LiteralPath $WebRoot -Recurse -File -Include *.config,*.json,*.xml -ErrorAction SilentlyContinue
foreach ($f in $configFiles) {
    try {
        $matches = Select-String -LiteralPath $f.FullName -Pattern 'insight\.sitefinity\.com|Sitefinity Insight|DigitalExperienceCloud|Progress\.Sitefinity\.Insight|apiKey|accessKey' -SimpleMatch:$false -ErrorAction Stop
        if ($matches) { $configHits += $matches | Select-Object -First 3 }
    } catch {
        # Ignore unreadable/binary-ish files

    }
    if ($configHits.Count -ge 3) { break }
}

$hasInsightEvidence = ($insightDll.Count -gt 0 -or $configHits.Count -gt 0)

if ($hasInsightEvidence) {
    $evidence = @()
    if ($insightDll.Count -gt 0) { $evidence += ('connector DLLs: ' + (($insightDll | ForEach-Object { $_.Name }) -join ', ')) }
    if ($configHits.Count -gt 0) { $evidence += ('config references in: ' + (($configHits | ForEach-Object { $_.Path } | Select-Object -Unique) -join ', ')) }
    Write-Result -Status 'VULNERABLE' -Message ("Sitefinity version $fileVersion ($branch) is in a vulnerable range and Insight integration evidence was found; " + ($evidence -join '; ')) -Code 1
}

Write-Result -Status 'UNKNOWN' -Message "Sitefinity version $fileVersion is in a vulnerable range, but no clear local evidence of active Insight integration was found. CVE-2026-7312 requires active Insight integration and non-default configuration; verify connector usage manually." -Code 2
07 · Bottom Line

If you remember one thing.

TL;DR
On Monday morning, treat this as a targeted HIGH: first inventory every internet-facing Sitefinity instance on affected 14.0-15.4 trains, then identify which ones actually use Sitefinity Insight and expose non-default service behavior. For those systems, apply temporary route restrictions, integration disablement where unused, and key rotation under the noisgate mitigation SLA of within 30 days; then complete vendor remediation by upgrading to the fixed build for that train under the noisgate remediation SLA of within 180 days. If you confirm a public-facing instance is both vulnerable and actively using Insight, do not wait for the full patch window before rotating keys and reducing exposure.

Sources

  1. NVD CVE-2026-7312
  2. CISA Known Exploited Vulnerabilities Catalog
  3. Progress Sitefinity docs - Authentication and web services
  4. Progress Sitefinity docs - Work with the Sitefinity Insight API
  5. NuGet - Progress.Sitefinity 14.4.8152
  6. NuGet - Progress.Sitefinity 15.4.8630
  7. Progress Sitefinity lifecycle policy
  8. WhatCMS - Sitefinity usage statistics
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.