FAQ about vulnerability management

Why does the same server report multiple instances of the same vulnerability?

Security Center detects application vulnerabilities per running process instance. If a server runs two instances of the same process with the same vulnerability (for example, two Tomcat services on different ports), each is reported separately. Software that is installed but not running is not scanned.

Why do scan results for vulnerabilities like Fastjson sometimes vary?

Security Center detects a vulnerability only when business logic calls the vulnerable component (such as a JAR package) at runtime. In a dynamic loading model, results vary depending on which components are active during each scan.

After the agent goes offline, why does the console still show vulnerability records?

Security Center retains vulnerability records after the agent goes offline, but they become stale and cannot be fixed, verified, or cleared. Staleness periods:

Does vulnerability scanning or proof of concept (POC) validation for urgent vulnerabilities affect business systems?

Typically no. POC validation sends only 1–2 harmless probe requests without any attack or destructive action. A minimal risk exists only if the target application is exceptionally fragile when handling unexpected input.

Why does a vulnerability scan sometimes trigger an out-of-memory (OOM) error?

The agent has a 200 MB memory limit. If a scan exceeds this limit, the OOM mechanism terminates the detection process (ALiSecCheck).

This is normal and unrelated to system-wide memory shortage. The limit is managed by cgroup aegisRtap0. OOM entries appear in dmesg logs. No action is required.

What is the scope of a vulnerability scan?

Scanning covers both the system and application layers:

How do I view the list of vulnerabilities that Security Center can detect?

1. Log on to the Security Center console.

2. In the left-side navigation pane, choose Risk Governance > Vulnerabilities.

3. In the overview section, find the Disclosed Vulnerabilities statistics card and click the total number to view all detectable vulnerabilities and their details.

Does Security Center support detection for vulnerabilities in services like Elasticsearch?

Yes. View detection results on the Application Vulnerability page in the console.

Does Security Center alert on CVE vulnerabilities that are not yet included in the vulnerability database?

Security Center only alerts on known vulnerabilities that are already included in the vulnerability database. If a CVE has not been officially disclosed or included, the system cannot identify the risk and does not send alerts. If a vulnerability has been disclosed with patches available but is still not detected, verify whether manual remediation or mitigation measures have already been applied. We recommend following Alibaba Cloud security advisories. Once a vulnerability is officially disclosed and the vendor releases a patch, Security Center updates its detection rules.

Where can I find the latest vulnerability rule classification after rule adjustments?

Some vulnerability rules may be removed from the application vulnerability category due to false positives and reclassified as system vulnerabilities. You can check the latest classification in the Supported vulnerabilities list on the Vulnerabilities page.

Does Security Center support Ubuntu 24.04? How do I manually scan for vulnerabilities?

Security Center supports manual vulnerability scanning. Mainstream Linux distributions are generally supported. To scan, log on to the console, go to Risk Governance > Vulnerabilities, select the region in the upper-left corner, click Quick Scan, and select the vulnerability types. Alternatively, on the Host page, select the target server and use the vulnerability scan option under Security Check. For specific OS version support, refer to actual scan results in the console.

Why do Security Center and third-party security software (such as Huorong) show different detection results?

Security Center primarily detects official Windows system patches (such as cumulative updates KBxxxxx), while third-party security software like Huorong may not cover these system-level patches or may use different detection strategies. Result differences are normal.

Why doesn't Security Center detect a vulnerability, while a third-party scanning tool (such as Qualys) or a manual check shows that it exists?

Third-party security scanners typically compare software version numbers against a CVE database to determine whether a vulnerability exists (for example, CVE-2020-15778). However, some of these vulnerabilities pose no real risk or require specific conditions to be exploited. Security Center instead detects vulnerabilities based on official security advisories published by the OS vendor, which is a different detection strategy from that used by third-party scanners. Consider the following common scenarios:

• The OS vendor backported the fix without changing the software version number. Third-party tools that rely on version number comparison may still report a false positive in this case. If the OS vendor has confirmed the vulnerability and fixed it by releasing a stable update package, Security Center recognizes the vulnerability as fixed and does not generate an alert. Run uname -r on the server to check the current kernel version and compare it with the version stated in the vulnerability advisory.

• The vulnerability has strict exploitation prerequisites or limited actual risk. Some vulnerabilities (for example, OpenSSH CVE-2020-15778) require an attacker to already have SSH logon permissions. If the server is not exposed to the Internet and the actual exploitable risk is low, Security Center does not include the vulnerability in routine scans based on its assessed risk. If you want to eliminate the potential risk entirely, you can manually upgrade the affected software as recommended by the third-party tool.

• The specific vulnerability is not covered by Security Center's detection rules, or the detection strategy differs from third-party scanners. Some Linux distributions (such as Alibaba Cloud Linux) publish their own security advisories. If the affected package is not installed on your asset, Security Center does not detect the related advisory. Some risk fixes, such as certain Windows virtio driver updates, are not assigned a CVE number and are therefore not covered by CVE-based detection. We recommend that you check whether the affected software is actually installed and follow the Alibaba Cloud Security notices.

• The vulnerable process is not running. Application vulnerability detection targets running process instances. If the vulnerable component is not loaded, or the corresponding service is not started, Security Center does not detect the vulnerability.

If the OS vendor does not provide a fix, or the vulnerability exists in software that came from a custom installation, Security Center does not currently support detection for that vulnerability.

Why does an inactive instance still show high-risk vulnerability alerts?

Possible reasons include:

• Legacy assets (instances or snapshots that were not fully released).

• Associated resource risks (such as configuration weaknesses in OSS, RDS, or other cloud products).

• Data synchronization delay.

If the alert status shows Passed, there is no active risk and it can be ignored.

Why do historical vulnerabilities appear and the security score change after disabling the "Show only real-risk vulnerabilities" toggle?

Application vulnerabilities may have been scanned previously but were not displayed because the toggle was enabled. After disabling the toggle, historical vulnerabilities are displayed, causing the security score to refresh. The score updates again after a period of time.

Does a new scan use or restore historical vulnerability data?

No. Security Center only retains currently valid vulnerability data (vulnerabilities detected within the last 30 days). Each scan is an independent detection based on the current asset state. Expired and cleared historical vulnerability records are not reloaded.

How do I distinguish between active scanning and passive detection in Security Center vulnerability scan results?

In scan results, entries marked as Web Scanner are from active scanning (sending probe requests via public IP for verification) and should be prioritized for remediation. Entries marked as Software Composition Analysis are from passive detection (comparing locally collected software version information via the Agent).

Why don't application vulnerability detection results show specific file paths?

Application vulnerability detection targets specific running process instances. If a vulnerability is detected but no specific file path is shown, refer to the suggestions in the vulnerability details or check common paths (such as JAR files in the Tomcat working directory). For complex vulnerabilities (such as Jackson deserialization), you may need to log on to the server and check the potential paths provided (such as /data/.../jackson-databind-*.jar).

Do Security Center vulnerability scan results overwrite historical data?

Yes. After a scan completes, results are automatically updated (overwritten) on the asset detail page in the console. You can view the latest results by navigating to Risk Governance > Vulnerabilities, or click Task Management in the upper-right corner to view scan task execution status.

Why does a newly purchased ECS instance already have vulnerabilities?

The operating system image used by an ECS instance has its software package versions frozen when the image is released. Linux and Windows vendors continuously release security patches, and an image cannot stay in sync with every subsequent patch. As a result, a newly purchased ECS instance may report recently disclosed vulnerabilities in system components, such as security updates for the kernel, Python, or OpenSSL. This is expected behavior. In addition, software that you install yourself after the purchase may introduce known vulnerabilities.

You can fix the vulnerabilities in the following ways:

• Security Center paid editions (Enterprise Edition and higher): Log on to the Security Center console, go to the Risk Governance > Vulnerabilities page, select the vulnerabilities that you want to fix, and then click Fix to perform a one-click fix.

• Security Center Basic Edition (free): Log on to the ECS instance manually and run a system update by using the package manager of the operating system, such as yum or apt.

Before you fix vulnerabilities, we recommend that you back up the system disk data by using the ECS snapshot feature to avoid compatibility issues during the fix.

Why isn't an urgent vulnerability included in the "High-priority Vulnerabilities (CVE)" list?

Urgent Vulnerability and High-priority Vulnerabilities (CVE) use different classification criteria, so they are shown separately. This is expected behavior:

• Urgent Vulnerability: A high-risk vulnerability type confirmed by Alibaba Cloud security engineers. These are typically application or middleware vulnerabilities (for example, Fastjson or Apache Dubbo) that are closely tied to your business code or configuration. One-click fix is not supported. These vulnerabilities are shown only on the Urgent Vulnerability tab, where you can perform detection and ignore operations.

• High-priority Vulnerabilities (CVE): A statistical view on the vulnerability overview page that is filtered by vulnerability risk score. It includes only system-layer vulnerabilities that support one-click fix, such as Linux kernel or system component vulnerabilities and Windows system component vulnerabilities.

Because the two categories use different remediation methods (one-click fix compared with detection followed by manual handling), they are displayed separately in the console, and Emergency Vulnerability entries are not counted in the High-priority Vulnerabilities (CVE) list.

Why do two servers show a significantly different number of vulnerabilities?

• Different OS versions or maintenance status: A server running an end-of-life (EOL) operating system (such as CentOS 5 or Ubuntu 12) continues to report high-risk vulnerabilities because the vulnerability database for that OS is no longer updated by the vendor, and these vulnerabilities cannot be fixed with one-click fix. A server running a currently supported OS version does not show these alerts. For more information, see the entry in this document about scanning and fixing vulnerabilities on end-of-life operating systems.

• Different running process states: Application vulnerability detection depends on components being loaded at runtime. If one server runs a specific middleware or database service and the other does not, only the server running that service reports the corresponding application vulnerability.

• Differences in installed software packages, Security Center edition, and vulnerability scan level configuration between the two servers can also lead to different vulnerability counts.

Why does Security Center detect a vulnerability even though I never installed the affected third-party software?

The detected software vulnerability may come from a component or dependency library preinstalled in the system image, so it can be detected even if you never actively installed that software. For more information, see the entry in this document about why a newly purchased ECS instance already has vulnerabilities.

We recommend that you check the impact description and the file path shown in the vulnerability details to identify the specific file that triggered the alert. If you confirm the alert is a false positive or determine that no fix is needed, you can Ignore the vulnerability, or add it to the whitelist based on the vulnerability type.

An alert mentions a middleware vulnerability such as Redis, but I can't find the corresponding cloud product instance. What should I do?

This type of alert usually points to middleware that you installed and manage yourself on an ECS server (for example, a self-managed Redis instance), not a managed ApsaraDB instance. Security Center's vulnerability detection covers host and container assets, not the internals of managed database instances.

We recommend that you use the IP address or hostname shown in the alert details to locate the corresponding ECS server, then confirm the installation and running status of the middleware on that server. Once located, follow the remediation documentation for that middleware to upgrade it manually, and return to the console to verify the fix afterward.

Why am I notified that an unfixed high-risk system vulnerability was found?

This notification indicates that a disclosed but unpatched security vulnerability exists in the operating system or installed software on an ECS instance. Common causes include: the system image has not been updated recently, or manually installed software is running an outdated version.

To resolve this, go to Vulnerabilities in Security Center, review the specific vulnerability details, and fix vulnerabilities in priority order — vulnerabilities that support one-click fix can be fixed directly in the console, and other vulnerabilities should be handled manually based on the vendor's advisory.

How do I stop automatic scanning for Emergency Vulnerability?

Log on to the Security Center console, go to Risk Governance > Vulnerabilities, click Vulnerability Management Settings in the upper-right corner, and find Urgent Vulnerability Scan Cycle. Change the cycle option to Stop to disable the periodic automatic scan task for Emergency Vulnerability. This option is available only when a scan cycle task already exists.

Application Vulnerability Scan Cycle offers only Every 3 Days, Every 1 Week, and Every 2 Weeks — there is no option to stop scanning. If you want to reduce the scan frequency for application vulnerabilities, set the cycle to Every 2 Weeks. There is currently no way to fully disable automatic scanning for application vulnerabilities through this setting.

Stopping or reducing the frequency of automatic scanning lowers how quickly new vulnerabilities are discovered. We recommend keeping periodic scanning enabled where possible, or running a manual scan as needed.

After connecting a new instance, why is there no data in Vulnerabilities or security alerts?

An instance that was recently connected to Security Center may take some time for data to sync and for the initial scan to complete, so the vulnerability management page may temporarily show no data.

We recommend that you click Scan on the Vulnerabilities page, select the vulnerability types you want to check, and wait for the scan task to finish before checking the results again. You can track the scan progress in Task Management.

If the instance still shows no data after the scan completes, and the agent is online and the instance status is normal, this indicates that no risks were currently detected on that instance, which is expected. Also confirm that the region selected in the upper-left corner of the console matches the region where the asset is actually located.

Why is the Fix button grayed out?

Most commonly, your edition does not support one-click fix. Basic Edition and Anti-virus Edition lack this feature. Purchase the Vulnerability Fixing value-added service, or upgrade to Enterprise or Ultimate Edition.

If your edition supports one-click fix, check for server-side issues:

Linux

Windows

Why can't application vulnerabilities be fixed with one-click fix?

System vulnerabilities (Linux software and Windows system vulnerabilities) reside in OS components with standardized remediation paths, enabling one-click fix.

Application vulnerabilities exist in self-deployed code or third-party software. Remediation depends on your business logic, so they must be fixed manually.

Why are there so many vulnerabilities on my server?

Older software accumulates vulnerabilities as new attack methods emerge. To focus on the highest-priority risks, enable the Show Only Exploitable Vulnerabilities toggle.

What should I do if I get a "Permission acquisition failed" error when fixing a vulnerability?

The file required for the fix is not owned by root.

1. In Security Center, view the vulnerability details to identify the specific file and its path.

2. Log on to the server and change the file owner to root.

3. Return to the Security Center console and retry the fix.

In what order are vulnerabilities fixed in a batch?

Linux software vulnerabilities and Web-CMS vulnerabilities are fixed in the order they appear in the console list.

Windows system vulnerabilities that require prerequisite patches are fixed first. The remaining vulnerabilities are then fixed in the order they appear in the console list.

Why is restarting ineffective after fixing an Ubuntu kernel vulnerability?

This happens when the GRUB boot order was manually modified before the fix. The system fix script cannot automatically set the newly installed kernel as the default boot item.

Solution 1: Automatically configure the new kernel

This solution abandons the original custom GRUB configuration and lets the system apply the default settings for the new kernel.

1. Before running the fix, log on to your Ubuntu server.

2. Run the following command:

      export DEBIAN_FRONTEND=noninteractive

3. Return to the Security Center console and run the one-click fix.

4. Restart the server as prompted. The system automatically enables the latest kernel.

Solution 2: Manually modify the boot order

Use this solution to keep the original GRUB configuration.

1. In the Security Center console, run the one-click fix and restart the server as prompted.

2. Log on to your Ubuntu server.

3. Modify the GRUB boot order to set the newly installed kernel as the default boot item. This typically involves modifying /etc/default/grub and running update-grub. See Modify the kernel boot order for ECS Linux CentOSModify the kernel boot order for ECS Linux CentOS.

4. Restart the server again.

Do I need to restart the system after fixing a vulnerability?

• Windows: A restart is always required.

• Linux Software Vulnerability: A restart is required if a kernel vulnerability was fixed, or if the vulnerability has a Restart Required tag on the Linux Software Vulnerability tab under Risk Governance > Vulnerabilities in the Security Center console.

Auto-fix usually does not cause server shutdown, but some kernel vulnerability fixes may require a restart. We recommend operating during off-peak hours and creating snapshots before fixing.

Why does a vulnerability rollback fail?

Two common causes:

• Agent offline: The rollback operation depends on the Security Center agent being online. If the agent is offline, the command cannot be delivered. Troubleshoot and resolve the agent connectivity issue first.

• Backup snapshot invalid: Rollback relies on the backup snapshot created before the fix. If the snapshot has expired or been manually deleted, the rollback cannot proceed.

Why does creating a snapshot fail when fixing a vulnerability?

• RAM user without permission: The RAM user lacks snapshot creation permissions. Use an Alibaba Cloud account for the operation. Overview of RAM usersOverview of RAM users.

• Non-Alibaba Cloud server: Snapshot creation for vulnerability fixes is supported only on Alibaba Cloud servers.

Does Security Center support vulnerability scanning and fixing for end-of-life (EOL) operating systems?

For OS versions that have reached end-of-life (such as CentOS 7.6), Security Center does not support vulnerability scanning or one-click fixing. If no vulnerabilities are detected, verify whether your OS version is within the supported range. If not, we recommend upgrading to a supported OS version, or assessing the risk and marking the vulnerability as Ignored in the console.

What is the impact scope of OS vulnerabilities when multiple services are deployed on the same server?

When multiple services are deployed on the same server, OS vulnerabilities affect all services on that server because they share the same OS environment. We recommend applying system patches to the entire server and creating a snapshot backup before the fix.

Do I need to restart the server after fixing a vulnerability? What is the impact on business?

• Windows system vulnerabilities: Server restart is required for patches to take effect. Restart causes brief service interruption. We recommend operating during off-peak hours and selecting Automatically Create Snapshot and Fix Risk for rollback.

• Linux kernel vulnerabilities: Restart is required. If the status remains Fixed and Pending Restarted after fixing, click Restart in the console or manually restart the server, then click Verify.

• Linux software vulnerabilities: A restart is required only when the vulnerability's advisory information on the Linux Software Vulnerability tab under Risk Governance > Vulnerabilities shows a Restart Required tag. Otherwise, no restart is needed.

• Business impact: Restart causes a brief service interruption. The fix process itself may also consume server resources and temporarily affect performance. We recommend performing the fix during off-peak hours and creating a snapshot backup beforehand.

• Risk of not fixing Windows system vulnerabilities: Leaving a Windows system vulnerability unfixed does not affect the normal operation of the system or your business, but it lowers system security and increases the risk of attack. We recommend evaluating the fix priority based on the vulnerability severity and business importance, and applying mitigation measures (such as access control) for vulnerabilities that you cannot fix immediately.

What are the risks of not fixing high-risk vulnerabilities (such as Linux Kernel ptrace)?

• Risk: High-risk local privilege escalation vulnerabilities (such as CVSS 7.8) can be exploited by attackers to steal sensitive files (/etc/shadow, SSH private keys) and gain root access, leading to full server compromise.

• Mitigation: If immediate fixing is not possible, restrict access via security groups and strengthen monitoring, but the root fix is still patching.

• SSL/TLS vulnerability location: For SSL/TLS information disclosure vulnerabilities (such as CVE-2016-2183), you can ping the domain to resolve the IP, then use CLB/K8s resources to locate the affected nodes for manual remediation.

Is the effect of Security Center auto-fixing Windows patches the same as manually downloading and installing them?

Yes. Security Center's fix feature calls system-level interfaces to install official Microsoft patches, producing the same result as manual download and installation.

If a vulnerability fix fails and I click Fix again, am I charged twice?

Security Center charges for vulnerability fixing per fix operation. Clicking Fix Now consumes a fix quota or triggers a charge. If a fix attempt fails, clicking Fix again for the same vulnerability does not result in an additional charge — you are charged only once for the entire process, until the vulnerability is fixed successfully.

For the specific unit price and billing rules, see the Security Center billing documentation.

Are there any special considerations when fixing database or middleware vulnerabilities (such as MySQL or Oracle)?

• Business impact: The fix operation itself does not change your database data, but a version upgrade usually requires a service restart, which may cause a brief business interruption.

• Backup recommendation: Before you fix the vulnerability, create an ECS snapshot or a database backup so that you can recover if the upgrade fails. When you fix the vulnerability in Security Center, you can choose Automatically Create Snapshot and Fix Risk. If you choose Fix Without Snapshot, you cannot roll back through a snapshot if an issue occurs afterward.

• Fix priority: Not every vulnerability requires immediate remediation. We recommend that you prioritize Urgent and High-risk vulnerabilities. For Medium- and Low-risk vulnerabilities, you can evaluate the business impact and fix them later, or choose to ignore them or add them to the whitelist after applying mitigation measures (for example, restricting access through security groups).

• Database and middleware vulnerabilities are typically classified as application vulnerabilities, which do not support one-click fix. You must upgrade the software manually on the server, and then return to the console to verify the fix.

What should I do if batch vulnerability fixing shows "no matching records" or an empty list?

Troubleshoot in the following order:

1. Check your edition authorization: One-click fix and batch fix require a paid Security Center edition or the vulnerability fixing capability. The Basic Edition (free) does not support one-click fix. Check the authorized edition on the Host page, and upgrade the edition or activate vulnerability fixing if needed.

2. Check the filter conditions: Check whether an overly strict filter is applied on the vulnerability management page, such as the Show Only Exploitable Vulnerabilities toggle, a specific vulnerability level, or a processing status. Clear the filters and refresh the page.

3. Check the selected region: Confirm that the region selected in the upper-left corner of the console matches the region where your assets are actually deployed. This is especially important for application vulnerabilities.

4. Check the vulnerability type: Confirm that the selected vulnerability type supports one-click fix. Batch fix is available only for types that support one-click fix, such as Linux Software Vulnerability and Windows system vulnerability. Application Vulnerability and Emergency Vulnerability support only scanning and manual remediation, not batch one-click fix.

What does it mean when a vulnerability is marked as fixed with the reason "Rule Removed"?

Rule Removed is one of the reasons shown for a resolved application vulnerability. It means the detection rule for this vulnerability has been retired, so Security Center no longer classifies the affected item as an application vulnerability going forward. Other reasons in the same category include the process no longer existing, the middleware no longer existing, and the middleware having been updated.

When you see this marking, no additional action is required. Continue to evaluate any related software vulnerabilities through your normal vulnerability management process.

Do I need to wait for a snapshot to complete before fixing a vulnerability? How do I roll back if the fix causes a business issue afterward?

• Snapshot timing before a fix: If you manually created a snapshot as a backup, we recommend waiting until the snapshot status becomes available before you fix the vulnerability, to ensure the backup is valid. When you fix the vulnerability, you can choose Automatically Create Snapshot and Fix Risk, or choose Fix Without Snapshot to save time — note that you cannot roll back using a snapshot if you choose the latter option.

• Rolling back after a fix: If the fix causes an application to become unusable or the system to behave abnormally, go to the Total Handled Vulnerabilities panel in the vulnerability overview, find the vulnerability with a Fixed status, click Roll Back, and select the snapshot that was created before the fix to restore the server. Rollback is available only for vulnerability types that support one-click fix, such as Linux Software Vulnerability and Windows system vulnerability, and is not supported on non-Alibaba Cloud servers.

• Troubleshooting rollback failures: A rollback failure is usually caused by the agent being offline, or the snapshot being deleted or expired. For details, see the entries in this document about why a vulnerability rollback fails and why snapshot creation fails when fixing a vulnerability.

Can I delete a high-risk vulnerability alert directly? How do I handle a vulnerability that does not need to be fixed or is a false positive?

• Deletion is not supported: A vulnerability record in Security Center reflects the actual detected state of your asset, so you cannot manually delete it.

• How to handle it: For vulnerabilities that you confirm pose no risk, are false positives, or that you choose not to fix for now, use Ignore or add the vulnerability to the whitelist to stop the alert.

• Difference between Ignore and Add to Whitelist: Ignore applies only to a single vulnerability instance on the current asset, and the vulnerability may be detected again after the affected process restarts or a subsequent scan runs. Add to Whitelist applies at the vulnerability (CVE) level and can be scoped to all assets or a specific asset group; it remains in effect until you manually delete the whitelist rule.

• Handling lower-severity vulnerabilities: Under the pay-as-you-go billing model, you can evaluate the business risk of Medium- or Low-risk vulnerabilities and choose not to fix them, managing the alerts through Ignore or Add to Whitelist instead.

Does an urgent vulnerability with an Unprotected or Protected status need attention?

• Status meaning: Emergency Vulnerability supports detection only, not one-click fix. Unprotected and its counterpart shown on the Urgent Vulnerability tab indicate whether Virtual Patching of Cloud Firewall is currently protecting the affected asset against the vulnerability. Unprotected means Cloud Firewall virtual patching has not been enabled for this vulnerability, and you can follow the link on the vulnerability to go to the Cloud Firewall vulnerability protection page and enable it. The remediation status of the urgent vulnerability itself is tracked separately, using statuses such as unfixed, fix failed, fixing, verifying, fixed, ignored, and stale.

• Troubleshooting: If a report mentions an urgent vulnerability risk that you cannot find in the console, go to Risk Governance > Vulnerabilities > Urgent Vulnerability tab and check for any unfixed urgent vulnerability, and confirm that the region selected in the upper-left corner matches your asset's region.

• Recommendation: A protected or unfixed-but-monitored status does not mean the risk is fully eliminated. Follow the recommendations in the vulnerability details to upgrade the affected component to a secure version, or use Virtual Patching of Cloud Firewall on the Vulnerability Prevention page for protection.

What should I do if vulnerability fixing on an ACK cluster is slow or inefficient?

• Check the fix task configuration: The efficiency of fixing vulnerabilities on a container cluster is affected by the concurrent processing of fix tasks. Check the relevant settings in the Security Center console to see whether the concurrency can be increased.

• Optimization suggestions: After adjusting the setting, monitor the fix progress. If a performance bottleneck remains, evaluate the issue together with the resource load on your cluster nodes, since fix tasks compete for the same resources as your workloads.

• You can check the progress of individual fix tasks and any failed nodes in Task Management.

How do I disable automatic vulnerability fixing to avoid extra charges?

In the console, go to Risk Governance > Vulnerabilities, click Vulnerability Management Settings in the upper-right corner, go to the Automatic Vulnerability Fixing Settings tab, and turn off the automatic fixing switch. After it is disabled, no fix tasks run automatically, and no fix quota is consumed by automatic fixing.

Before disabling this feature, confirm the scope of your current automatic fixing policy so that you do not unintentionally disrupt an existing operational plan.

The automatic fixing card on the Security Center overview page is used only to enable this feature and jump to the settings page above; disabling automatic fixing must be done from Vulnerability Management Settings.

After Microsoft releases a patch, do I need to wait for Security Center to sync before I can fix the vulnerability?

No, you do not need to wait. You can install the latest cumulative update directly on the server through Windows Update. After installation, return to the Security Center console and click Verify on the vulnerability to update its status. If the status does not update immediately, it will be picked up in a later periodic scan.

The effect of installing the official patch manually is the same as using Security Center's auto-fix feature — see the entry in this document about whether auto-fixing Windows patches produces the same result as manual installation.

Does Security Center support generating and exporting vulnerability scan reports?

• Application vulnerability reports: Pay-as-you-go versions need to upgrade to Comprehensive Host Protection or higher to support application vulnerability scanning. In the console, go to Risk Governance > Vulnerabilities > Application Vulnerability to view and export the list. Independent reports for website URLs are not supported.

• Specific ECS instance vulnerabilities: Go to Asset Center > Host, search for the target server, enter the detail page, and click Vulnerability Details > Application Vulnerability to view and export.

• Report source verification: Check whether the Scan tool field shows Alibaba Cloud Security Center and the report type includes Host vulnerability scan.

• High-risk vulnerability reports (such as Nacos): View management events in the console's Security Management module.

• Dedicated vulnerability scan report: Security Center does not provide a dedicated vulnerability scan report. To obtain a vulnerability scan report, purchase the Security Assessment service, which includes host security assessment (vulnerability scanning) and lets you download a security assessment report.

How do I determine if my Linux kernel version is affected by a specific CVE?

1. Run uname -r to check the current kernel version and compare it with the affected version range in the CVE advisory.

2. Example: If the CVE affects kernel versions 4.14 to 6.18.21 and 6.19.11, and the current version is 3.10.0, the server is not affected.

3. Visit the Alibaba Cloud official vulnerability risk and fix announcement page for specific impact details.

What is the execution order and concurrency advice for batch vulnerability fixing?

• Execution order: Linux software vulnerabilities are fixed in console list order. Windows system vulnerabilities prioritize prerequisite patches first.

• Concurrency: Wait for the previous batch to complete before starting the next to avoid resource conflicts.

• UI not responding: If the UI shows Sending command with no response, this may be a display delay. Manually refresh the page to see the Fixing status.

• Duration: Linux auto-fix typically takes minutes to tens of minutes depending on vulnerability count, server performance, and network. If it takes too long, check disk space (3 GB or more recommended), package manager conflicts, or permission issues.

Does Security Center support vulnerability fixing for servers without public IP addresses?

Yes. As long as the server has the Security Center Agent installed and network connectivity is normal, vulnerability fixing is supported. When using Alibaba Cloud internal sources, no public IP is needed. Prerequisites: Security Center service must be activated and the Agent must be online.

What are the considerations for enabling automatic vulnerability fixing?

• Not enabled by default: Auto-fix requires manual policy configuration before taking effect.

• Scope limitation: Only supports non-kernel Linux system vulnerabilities and depends on the one-click fix feature (version support required).

• Recommendations: Test in a test environment first. Ensure snapshot backup policies are configured. Schedule during off-peak hours. Avoid enabling for all assets to prevent excessive consumption of fix quotas.

If yum update kernel returns "Nothing to do" or shows no upgrade success message, do I still need to restart the server?

Yes. Even if yum update kernel returns Nothing to do, or does not display an upgrade success message, we recommend that you restart the server. This ensures that the kernel change takes full effect and that the running system state matches the installed kernel.

After the restart, go to the vulnerability details page in the Security Center console and click Verify to confirm whether the vulnerability status has been updated to fixed. If the status does not update after verification, see the entries in this section about vulnerabilities that remain unfixed or show no response after manual verification.

A vulnerability has been fixed, but Security Center still reports it. What should I do?

Some vulnerabilities, particularly Linux kernel vulnerabilities, require a restart. On the vulnerability details page, click Restart. After the restart, click Verify. If the status shows Fixed and Pending Restarted, the fix succeeded.

The host has not installed a specific patch, but the Windows vulnerability shows as fixed. Why?

This is expected. Windows security updates are cumulative: each monthly patch includes all prior fixes. When Security Center detects the latest cumulative update, it marks all older vulnerabilities covered by that update as fixed.

To confirm whether a specific older vulnerability is covered, visit the official Microsoft patch website and search for the latest installed patch by its KB number. Check its package details to verify coverage.

After fixing a vulnerability, why does it still show "Not fixed"?

Three possible causes:

1. Verification delay: After a manual fix, click Verify to trigger an instant scan. The status update takes a few minutes.

2. Console cache: Force-refresh the page or wait a few minutes.

3. Incomplete fix: The fix may not have fully succeeded, or there may be multiple vulnerability paths with only one fixed. Recheck the fix steps.

Can Security Center automatically verify vulnerabilities in "Fixed and Pending Restart" state?

No. Restart the server from the Security Center console or manually, then click Verify to confirm whether the fix succeeded.

Why is there no response when I manually verify after fixing a vulnerability?

Two possible causes:

• Scan level not configured: Security Center only updates vulnerabilities whose severity level is selected in Vulnerability Settings. Verify that the scan levels cover the target vulnerability.

• Agent offline: The Verify function requires a live connection between the console and the agent. If the agent is offline, resolve the connectivity issue first, then retry.

After fixing a vulnerability, why does it still show unfixed, pending restart, or no response when I click Verify?

• Handling the "pending restart" status: A Linux kernel vulnerability, or any vulnerability tagged Restart Required, requires a server restart to take effect after the fix. On the vulnerability details page in Security Center, you can click Restart directly (available only for Linux Software Vulnerability and Windows system vulnerability in the Fixed and Pending Restarted state, and not supported for non-Alibaba Cloud servers), or log on to the ECS console or the server and run reboot. After the restart, click Verify to update the status.

• Restarting once for multiple vulnerabilities: If several vulnerabilities require a restart, you can fix each one individually to install the patches, and then restart the server once at the end. You do not need to restart separately for each vulnerability.

• No response after clicking Verify: If the status does not change for a long time after you click Verify, see the entry in this section about why manual verification shows no response after fixing a vulnerability.

• Delay in console updates: After you ignore or fix a vulnerability, the console display may be updated with a short delay. This is normal. You can wait for the automatic update or trigger verification manually.

How do I view the failure notification after a vulnerability fix fails?

How to view: On the Vulnerabilities page in the Security Center console, click the number under Fixing. In the Fixing panel, find the failed vulnerability and click the icon in the Status column to view the failure notification in the Cause Details dialog box.

Notification content: The failure notification shows the specific reason for the fix failure, the corresponding error code (if available), and suggested actions.

How do I handle error codes in fix failure notifications?

Follow the solutions provided in the Troubleshoot causes of vulnerability fixing failures documentation for the specific error code shown in the failure notification.

Does manually fixing a vulnerability cause Security Center to generate false positive attack alerts?

No. Manually updating vulnerability patches does not cause Security Center to generate false positive attack alerts. If the console still shows Unfixed after manual remediation, click the Verify button or wait for the data status to update automatically.

Why does Security Center detect a vulnerability under /usr/share/doc? Can the same vulnerability reappear after a fix?

• Cause of vulnerabilities under /usr/share/doc: Files in this directory (for example, files related to libpq5 or python3-twisted) are usually documentation or sample files bundled with the base system image. These files can have version metadata that matches an entry in the vulnerability database, which triggers an alert — this is expected detection behavior. To resolve the alert, upgrade the affected component, or add it to the whitelist after confirming there is no actual operational risk.

• Why a vulnerability can reappear: A fix only remediates the version detected at that time. If a subsequent system or application update introduces a new vulnerability, a configuration changes, or security best practices are not followed, a new vulnerability record can still be detected.

• Recommendation for ongoing protection: We recommend running scans regularly, following official security advisories, and using baseline checks to harden the system, rather than relying on a single fix.

Security Center still reports a kernel vulnerability after an upgrade. What should I do?

1. Confirm the kernel is upgraded. Run the following commands to check the running kernel version and verify it meets the requirements in the vulnerability details: Confirm the system starts using the new kernel:

      uname -av
      cat /proc/version

      cat /etc/grub.conf

2. Remove old kernel packages. List all installed kernel packages and identify old versions: Uninstall the old kernel package: Alternatively, use the distribution-recommended method. For CentOS/Red Hat:

   Important

   Before removing old kernel packages, create a snapshot or image for the current instance in the Elastic Compute Service console.

      rpm -qa | grep kernel

      rpm -e kernel-<old_version_number>

      yum remove kernel-<old_version_number>

3. Ignore the alert (optional). If the running kernel has already fixed the vulnerability, ignore the alert:

   1. Log on to the Log on to the Security Center console.

   2. In the navigation pane on the left, choose Risk Governance > Vulnerabilities. In the upper-left corner of the console, select the region where your asset is deployed: Chinese Mainland or Outside Chinese Mainland.

   3. On the Linux Software Vulnerability tab, find the vulnerability and click its name.

   4. In the Actions column, click the icon and select Ignore.

How do I manually update an Ubuntu kernel?

The following example updates kernel 3.1* to kernel 4.4 on Ubuntu 14.04.

1. Confirm the current kernel version is 3.1*:

      uname -av

2. Check whether the latest kernel update package is available:

      apt list | grep linux-image-4.4.0-94-generic
      apt list | grep linux-image-extra-4.4.0-94-generic

3. If no related update is available, run apt-get update to retrieve the latest package list.

4. Install the kernel update:

      apt-get update && apt-get install linux-image-4.4.0-94-generic
      apt-get update && apt-get install linux-image-extra-4.4.0-94-generic

5. Restart the server to apply the new kernel.

6. After the server restarts, verify the kernel update:

      uname -av

      dpkg -l | grep linux-image

What should I do if I get a kernel incompatibility notification when fixing a kernel vulnerability?

Symptom: After running a one-click fix for a kernel vulnerability in the Security Center console, the fix fails and the failure notification shows a kernel incompatibility error.

Cause: The server's kernel version is incompatible with the target fix version. This can occur if the kernel was manually modified, a non-standard version is in use, or the version gap is too large for a normal upgrade.

Resolution:

Solution 1: Use force fix

If you are confident your workloads will not be affected, use force fix to bypass the compatibility check:

1. Close the failure notification dialog.

2. In the Unhandled Vulnerabilities section, click Fix in the Actions column for the target server.

3. In the dialog box that appears, select the Mandatory Fix checkbox.

4. Select a remediation method and click Fix Now.

   Important

   Force fix bypasses the client compatibility check, which may introduce risks. We recommend selecting Automatically Create Snapshot and Fix Risk to retain rollback ability.

5. Click Fix Now.

Solution 2: Manually update the kernel

If force fix is not suitable, refer to How do I manually update an Ubuntu kernel? for manual upgrade steps.

When can I use force fix? What are the risks?

When to use: Force fix applies when:

• When a one-click fix fails due to kernel incompatibility.

• When you are confident the system environment meets the fix requirements but the compatibility check did not pass.

How to use: Select the Mandatory Fix checkbox in the fix dialog box.

Risks: Force fix bypasses the compatibility check, which may cause:

• Compatibility issues after the fix that may cause business disruptions.

• Kernel upgrade failure that may prevent the system from booting normally.

Recommendation: Before using force fix, select Automatically Create Snapshot and Fix Risk for quick rollback. Only use force fix when you are confident your workloads will not be affected.

What should I do if a vulnerability shows no available updates?

No official patch available

When the update command returns a message such as already installed and latest version or No Packages marked for Update, the official update source has not released a patch. This may affect packages such as Gnutls, Libnl, and MariaDB. Wait for the official software source to release an update.

OS version reached end of life (EOL)

If the software package is the latest version supported by the current system but still does not meet the fix requirements, the OS version may be past its EOL (for example, CentOS 6.x). Two options:

• Upgrade the OS to a version within its official support period.

• After assessing the risk and confirming it is manageable, ignore the vulnerability in the Security Center console.

No fix option is shown, or the fix status has not updated

• Rescan: On the vulnerability management page, run a new scan to check for the latest fix option.

• Wait for sync: If no fix option appears after rescanning, Security Center may still be verifying and syncing the remediation for this vulnerability. Wait for the update.

• Alternative approach: For certain kernel vulnerabilities that have no fix entry point in the console for an extended period, follow the operating system vendor's official Security notices to remediate manually, or apply a temporary mitigation, and consider ignoring the vulnerability after you confirm the risk is under control.

How do I handle a timeout when connecting to the Alibaba Cloud Yum source?

If the connection times out, an error similar to the following appears:

[Errno 12] Timeout on http://mirrors.aliyun.com/centos/6/os/x86_64/repodata/repomd.xml: (28, 'connect() timed out!')

1. Check whether DNS resolution is working. Run ping mirrors.aliyun.com or nslookup mirrors.aliyun.com.

2. If network access is normal, wait a moment and retry. The timeout may be caused by temporary network fluctuations or high traffic on the mirror source.

How do I clear Windows vulnerability patch packages from the client directory?

After a one-click fix, the agent automatically downloads, installs, and removes the patch package.

If the patch remains after 3 days, manually clear it:

1. Log on to the Log on to the Security Center console.

2. In the navigation pane on the left, choose System Configuration > Feature Settings. In the upper-left corner of the console, select the region where your asset is deployed: Chinese Mainland or Outside Chinese Mainland.

3. If client self-protection is enabled, go to the server details page in Asset Center and turn off the Client Protection toggle.

   Note

   Client self-protection blocks requests to delete or download process files from the agent directory on Windows servers. If you have not enabled client self-protection, skip this step.

4. Log on to the Windows server with administrator permissions and delete the patch package from the following directory:

   Important

   The default patch package path is C:\Program Files (x86)\Alibaba\Aegis\globalcfg\hotfix.

5. (Optional) On the server details page, turn on Client Protection.

Does the vulnerability path showing "none" in Security Center scan results require action?

This typically indicates that a vulnerability was detected but the specific file path could not be located. This is normal behavior and no special action is required.

Is the Security Center vulnerability fix resource package automatically subscribed or does it need manual activation?

Users need to manually claim it in the console for it to take effect. It is not automatically subscribed or activated by default.

Penetration testing and vulnerability scanning filing FAQ

• Application submission failure: Ensure you only enter the real public source IP address (the machine initiating the scan), not the target server IP being scanned.

• "Not my asset" prompt when adding IP: This usually means the IP belongs to another Alibaba Cloud account. Switch to the account that owns the IP and submit the application from that account.

• Third-party scanning tool configuration: Add the third-party scanning tool's IP to the whitelist in the security management platform and submit a penetration testing application.

Why am I still charged for scheduled scanning after canceling paid services?

The pay-as-you-go features may still be enabled. Solution:

1. Log on to the Security Center console.

2. In the left-side navigation pane, choose Overview to go to the Overview page.

3. In the Enable Pay-as-You-Go Service section in the upper-right corner of the page, you can:

   • Disable specific services: Turn off the switch for the corresponding service to stop billing for that service only.

   • Disable all services at once: Click the Deactivate button in the upper-right corner of the page to disable all pay-as-you-go features at once.

4. Top up and settle any outstanding balance to prevent impact on other services.

How do I query Security Center operation logs in ActionTrail?

Use the ActionTrail console at ActionTrail console - Security Center events. If no data is returned, check the region setting in the ActionTrail console — switch to the region where the resources are located (for example, Shanghai), as operation logs may be stored in different regions.

Why doesn't the CVE-2019-14439 urgent vulnerability detection path show the container environment?

Problem: The CVE-2019-14439 urgent vulnerability detection path does not show the container environment. The path is /skywalking/oap-libs/jackson-databind-2.9.5.jar. The environment found on the server is a container environment, but the local environment does not contain the Jackson library. In contrast, the Spring Framework JDK >= 9 remote code execution vulnerability (also an urgent vulnerability) shows it exists in containers.

Answer: Detection scripts vary by vulnerability type. For scenarios that require scanning container environments, we recommend using the application vulnerability scanning tool.

How do I query the CVEs fixed by Windows monthly patches?

1. Log on to the Security Center console.

2. In the left-side navigation pane, choose Risk Governance > Vulnerabilities, select the Windows System Vulnerability tab, and get the patch number you need to query (for example, patch 5043050).

3. Visit the Microsoft patch link and replace the patch number at the end with the one you need to query. For example: https://support.microsoft.com/help/5043050

4. On the opened page, click xx Month xx Security Update to view the list of CVEs fixed by that KB package.

5. Compare the CVE list with the CVE list displayed in the CVE ID column in Security Center to ensure consistency.

I received a notice from a regulatory authority about a high-risk vulnerability, but the asset already has access control in place. How do I fill out the remediation report?

• Remediation principle: If you confirm that the affected asset is strictly restricted through measures such as security groups or network access control lists (for example, only trusted IP addresses are allowed access), and the vulnerability cannot be fixed immediately for business reasons, you can describe the access control configuration as a compensating measure.

• Report content: In the remediation report, describe the current state and impact scope of the vulnerability, the access control policy already implemented (with configuration screenshots), your risk assessment conclusion, and the planned fix timeline, to demonstrate that the risk is under control.

• Follow-up: A compensating measure does not replace fixing the vulnerability. We recommend completing the fix during a suitable business window and verifying the fix afterward to update the vulnerability status.