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 Scan Now, 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 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 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 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 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: Usually no restart required, unless the vulnerability advisory specifies Restart required.

• Specific CVE example: For CVE-2024-57979, if the console does not indicate a restart is needed, no restart is required.

• Business impact: Restart causes service interruption; the fix process may consume resources causing slowness. We recommend backing up (snapshot) and testing in a test environment first.

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.

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 Assets > 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.

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.

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.

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.

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.

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 Settings > 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 Pay-as-you-go 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 Disable All Pay-as-you-go Services 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.