CISA's required action for CVE-2023-48365 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Qlik Sense in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What matters first when you are patching an exploited Qlik Sense flaw?
The first job is not just “apply a patch,” it is to confirm whether any Qlik Sense deployment is still reachable, internet-exposed, or running the vulnerable path at all. For an exploited flaw, patching and exposure reduction are inseparable: if the vendor update cannot be applied immediately, the safer interim state is to remove external access or discontinue the product until you can validate a fixed condition.
Use the Zero-Day and Exploited Vulnerabilities Guide to drive the response as an exploited-vulnerability workflow, not a routine maintenance task. The practical sequence is asset discovery, exposure reduction, vendor-directed mitigation, then verification that the mitigation actually changed the attack surface.
How should you handle verification, rollback, and exposure reduction?
Start by finding every Qlik Sense instance, including forgotten test systems, cloned environments, and externally published nodes. Then validate that the vendor security update or documented mitigation is in place on each one. If patching is delayed, remove public reachability first, because an exposed unpatched service is still a live target even if the rest of the estate is already remediated.
That is where Vulnerability Management Guide becomes useful: it frames the work as scope, prioritisation, exception handling, and verification, which is exactly what an exploited CVE demands. Treat any waiver or delay as temporary and time-bound, and document the compensating control that actually reduces exposure.
What should you check after the patch or mitigation is applied?
After remediation, assume the flaw may already have been used and review logs, authentication history, and web access records for signs of suspicious activity before the fix date. Focus on unexpected tunnelling use, unusual source IPs, new administrative actions, and evidence that the service was accessed in a way that matches exploitation rather than normal user traffic.
For response discipline, the CISA Known Exploited Vulnerabilities Catalog is the authoritative cue that this is not hypothetical risk, and the NIST National Vulnerability Database is the place to confirm the record and track the product entry while you work through your environment. If you find evidence of compromise, rotate any credentials, tokens, or service accounts that the affected system may have exposed.
Risk and Threat Considerations
This type of flaw matters because an internet-reachable tunnelling service can turn a single vulnerable application into a broad foothold. Once an attacker reaches the service path, they may be able to abuse it for unauthorized access, lateral movement, or post-exploitation activity before defenders notice.
Failure mechanism: The weak point is usually not just the code defect itself, but the combination of exposed service, delayed patching, and incomplete monitoring. If the system remains reachable while you are planning remediation, the attacker keeps a usable attack path.
Impact: The practical consequences are unauthorized access, possible persistence, and the need for a deeper compromise assessment than a normal patch cycle would require. In an exploited case, remediation often has to include containment, log review, and credential rotation, not just software replacement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE response centers on finding, patching, and verifying vulnerable assets. |
| Recommendation — Prioritize discovery, remediation, and verification for every exposed Qlik Sense instance. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about applying vendor fixes or mitigations for an exploited software flaw. |
| RA-5 — Vulnerability Monitoring and Scanning | The response requires locating all instances and checking for exposure before and after remediation. | |
| Recommendation — Apply the vendor update or documented mitigation, then verify the remediated state. Scan for all Qlik Sense instances and validate exposure status before closing the issue. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The flaw affects application exposure and mitigation handling for a networked product. |
| Recommendation — Treat the exposed tunnelling path as an architectural risk and reduce reachability until fixed. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | HTTP tunnelling exposure and mitigation affect how traffic to the service is protected in transit. |
| Recommendation — Restrict or secure the reachable service path while remediation is completed. | ||
Practitioner Guidance
What to verify: Confirm every Qlik Sense deployment by inventory, not by assumption, and verify the fix state on each instance separately. A single missed server can keep the vulnerability exploitable even when the rest of the estate is already patched.
Decision rule: If the vendor mitigation cannot be applied immediately, reduce exposure first by removing internet access or taking the product out of service. Do not leave an exposed vulnerable instance running while you wait for a convenient maintenance window.
Practitioner takeaway: For a known exploited CVE, the real control is verified reduction of attack surface plus post-fix compromise hunting, because patching alone does not prove the system was safe before remediation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org