OESIS Framework Release Announcement | October 2026

We are thrilled to unveil the latest updates to the OESIS Framework this month. Get ready to supercharge your endpoint protection solutions with expanded support for more products and some new, exciting features. Build stronger defenses with advanced capabilities that integrate seamlessly into your products. Prepare for an epic upgrade that'll take your security to the next level.

FEATURE: COMPLIANCE

ENHANCEMENT, WINDOWS, ENGINE UPDATE NEEDED

GetRealTimeProtectionState (method 1000) now returns a new string field state alongside the existing enabled boolean, so callers can tell a security product that is genuinely off from one that is still starting up. Posture checks that run right after boot or login previously saw enabled: false for an agent whose services had not finished initializing, and had no way to distinguish that from real-time protection being switched off.

The state field carries exactly one of four values, and is never null or empty:

• enabled — real-time protection is on
• disabled — real-time protection is off, or the backing services are stopped
• initializing — the backing services are still starting
• unknown — the service state could not be queried

state is returned for every product that supports method 1000. The computation and meaning of enabled and of the details object are unchanged, so this is an additive, backward-compatible change. We recommend treating initializing as a signal to wait and retry rather than to block, and applying a short retry before treating disabled as final during the boot window.

FEATURE: PATCHING

NEW FEATURE, WINDOWS & MACOS, ENGINE UPDATE NEEDED, CODE CHANGE

You can now roll an installed application back to an earlier version through InstallFromFiles, so a version that turns out to be faulty after patching can be reversed in a single call, without chaining a separate uninstall and reinstall.

InstallFromFiles accepts a new optional boolean input, enable_rollback, which defaults to false. Set it to true together with requested_version, and the SDK uninstalls the currently installed version and then installs the version you requested. The SDK checks that the application can be rolled back to that version before it touches the endpoint, and returns an error without making any change if it cannot:

• WAAPI_ERROR_INVALID_INPUT_ARGS (-20) — enable_rollback is true but requested_version was not supplied
• WA_VMOD_ERROR_PRODUCT_NOT_SUPPORTED (-1026) — the application does not support removal or fresh installation
• WA_VMOD_VERSION_LOCK_NOT_SUPPORTED (-1052) — the requested version is not recognized, or no version-specific installer is available for it

If the uninstall step fails, the SDK returns WAAPI_ERROR_UNINSTALL_SERVICE_FAILED (-89) and does not proceed to install. If the install step fails, it returns WA_VMOD_ERROR_INSTALLATION_FAILED (-1034), and the application may be left uninstalled. Requesting the version that is already installed runs the same flow without error, so one code path covers both cases. The output of InstallFromFiles is unchanged.

To let you determine which versions are valid rollback destinations ahead of time, every package entry under each patch in patch_aggregation_v2.json now carries a boolean is_rollback_target. It is true when the application can be rolled back to that version, and false or absent when it cannot. This requires using patchv2.dat on the endpoint and patch_aggregation_v2.json on the server side.

*You will need to make a code change to implement this feature. Please contact the OPSWAT team to assist with this*

FEATURE: COMPLIANCE

ENHANCEMENT, ALL PLATFORMS, ENGINE UPDATE NEEDED, CODE CHANGE

UpdateDefinitions (method 1003) now accepts an optional skip_connection_check boolean input. Before running a definition update, the method checks that the endpoint has internet connectivity, and on endpoints that block general internet access while still allowing security vendor update traffic, that check failed even though the update itself would have succeeded.

Pass "skip_connection_check": true in the 1003 json_in to bypass the connectivity check and proceed directly to the update. When the flag is omitted or set to false, the method behaves as before.

*You will need to make a code change to implement this feature. Please contact the OPSWAT team to assist with this*

FEATURE: PATCHING

ENHANCEMENT, WINDOWS, DATA UPDATE NEEDED

The server-side patch_system_aggregation.json now includes non-security and out-of-band Windows updates, which were previously missing from the file even though they were supported on the endpoint side. Existing records are unchanged, and the file schema is unchanged.

The addition takes the file from 42,911 to 58,269 records, an increase of roughly 35%, and the new records cover 2,040 distinct KB articles. Consumers should plan for the larger file and should not assume every record carries CVE or severity data: most non-security KBs have no associated CVEs, carry a severity of unknown, and report requires_reboot as maybe.

FEATURE: PATCHING

ENHANCEMENT, LINUX, ENGINE UPDATE NEEDED

InstallMissingPatches (method 1014) on apt-based Linux distributions now returns specific error codes with native detail in error.error_message, instead of a bare WAAPI_ERROR_GENERAL (-1). Download and installation failures previously collapsed into a single generic code, so the underlying cause was not visible to the integrator.

The following codes are now returned with accompanying detail:

• WAAPI_ERROR_ACCESS_DENIED (-22) — the operation requires administrator privileges
• WAAPI_ERROR_INVALID_INPUT_ARGS (-20) — the patches array is missing or empty, auto_repair is invalid, patches.product or patches.title is missing or empty, or patches.version is present but empty
• WAAPI_ERROR_RESOURCE_BUSY (-70) — the package manager resource is currently busy

error_message is not encrypted even when encrypt_sensitive_info is set to true. The scope is JSON-level error responses. We recommend logging and surfacing error.error_message for triage.

FEATURE: ALL MODULES 

ENHANCEMENT, MACOS, DATA UPDATE NEEDED 

Following Apple's general release of macOS 27, the SDK now supports it in production for detection and compliance, and for vulnerability assessment. The macOS 27 operating system identifier is live on production data, and the compliance modules that were previously validated against the beta, including Gatekeeper, the built-in firewall, FileVault, Packet Filter and iCloud, now report against the general release. 

Vulnerability assessment reports CVEs for the installed macOS 27 version. Note that macOS 27 runs only on Apple Silicon, so Intel-based Macs stay on their current macOS release and are unaffected by this update. 

FEATURE: VULNERABILITY ASSESSMENT

NEW FEATURE, WINDOWS, ENGINE UPDATE NEEDED, CODE CHANGE

We are adding vulnerability assessment for Windows drivers & BIOS, closing the gap where detected driver patches carry no vulnerability context. The SDK will identify and report the CVEs associated with installed drivers, including severity and affected driver version, for the same device models supported by driver patching.

Driver CVEs will also be linked to the patches that remediate them, so you can correlate the exact vulnerabilities present on a device with the available fixes, and the driver vulnerability data will be available for both endpoint and server-side use cases. Driver vulnerability assessment and driver patching are both covered under the VAPM license.

*You will need to make a code change to implement this feature. Please contact the OPSWAT team to assist with this*

FEATURE: VULNERABILITY ASSESSMENT

ENHANCEMENT, ALL PLATFORMS, DATA UPDATE NEEDED

We are adding support for CVSS v4, the latest version of the Common Vulnerability Scoring System published by FIRST, to our vulnerability data. CVSS v4 refines how exploitability and impact are measured and provides a more accurate severity signal than earlier scoring versions.

CVSS v4 scores will be carried alongside the existing scoring data where available, so customers can adopt v4-based prioritization without losing current behavior.

FEATURE: COMPLIANCE 

NEW FEATURE, ALL PLATFORMS, ENGINE UPDATE NEEDED 

We are adding a dedicated EDR/XDR category to the SDK, so an EDR/XDR product can be identified directly from its category in DetectProducts results rather than reconstructed from the individual antimalware, firewall and other components it installs. 

Products can belong to more than one category, so adding the EDR/XDR category does not remove or replace any existing category assignment, and the existing edrxdr label continues to work unchanged for integrations that rely on it. A support chart will accompany the new category, covering the methods available for EDR/XDR products. 

3.1 Engine Release Cadence Change (Starting October)

RELEASE SCHEDULE UPDATE, ALL PLATFORMS

Starting in October, we will update our Engine Package release cadence from weekly to bi-weekly. Under this new schedule, releases will occur twice per month, once in the second week and once in the fourth week of each month. This change aligns with our new development framework, enabling more accurate estimations, clearer updates, and more reliable on-time releases. We believe this adjustment will help us deliver higherquality updates more consistently.

*The initial rollout timeline has been revised from April to October. If you have any concerns or need clarification on this update, please contact the OPSWAT team to assist with this*

3.2 End of Support for AppRemover package with the old engine on macOS

END OF SUPPORT, MAC

As we have refactored the AppRemover module on macOS to provide a more optimized and streamlined experience, two packages of the AppRemover module on macOS are being maintained on the My OPSWAT Portal: AppRemover OSX and AppRemover OSX V2.

As of January 1, 2026, the OSX package has been removed. We recommend upgrading to AppRemover OSX V2 to ensure your system receives all new updates and comprehensive technical support for the AppRemover module.