One low-privileged login turns Adobe Connect's 9.9 SQL injection into code execution

Sorting this release by CVSS score barely separates the flaws. Six of the seven critical ones score 9.3 or higher ^[4]. A dev.to write-up argues that Connect teams should not hold this release for the next maintenance weekend, and it sorts the flaws by weakness type instead ^[18][19]. That sort puts the SQL injection in a group of its own. It is the only flaw Adobe ties to code execution from a low-privileged start with no mention of user interaction ^[6]. The script injection flaws are also critical, but they need a victim to interact with crafted content ^[6].

The top score in this release went to one of the oldest vulnerability classes in the field ^[15]. According to the write-up, an injection that ends in code execution moves the attacker from reading data to controlling a service component ^[16].

For a window that cannot cover every instance at once, the write-up gives this order ^[9]:

1. CVE-2026-75682, the code-execution SQL injection. 2. Flaws that need no credentials, starting with the CVE-2026-34689 path traversal ^[7]. 3. The interaction-dependent script injection flaws. 4. Everything else.

I agree with that order for Connect servers that enrol outsiders, the first deployment pattern the write-up lists ^[10]. On a closed internal deployment with a short, known user list, I would expect the traversal to have a stronger claim on first place, because it asks only for network reach ^[7]. Internal servers reachable from VPN segments or third-party support networks are also on the write-up's list ^[10]. For those, the thing to check is how large the reachable network actually is.

One checklist item is good engineering. The write-up says to confirm the patch level from the application itself, not from a change record ^[12]. A change record shows an upgrade was scheduled. The version the running server reports shows it happened ^[12].

The exposure figure needs the same care. A ZoomEye query for app="Adobe Connect" returned 23,660 instances, and the write-up says plainly that these are product fingerprints, not confirmed vulnerable hosts ^[11]. For the count to measure exposure, the fingerprint would have to carry a version, and the matched hosts would have to run builds older than 12.12 ^[8]. The write-up does not say whether the query distinguishes versions. A public internet index also cannot see internal deployments reached only over VPN ^[10].

For servers that must wait, the write-up recommends restricting management and administrative interfaces to trusted networks during the upgrade ^[13]. It also recommends segmenting the service from identity infrastructure and monitoring the host for unexpected outbound traffic ^[14]. Its account review targets this bug directly. It covers every account with meeting-hosting or content-upload permissions, since the injection needs only a low-privileged login ^[13].