Vulnerability management FAQ

Scan behavior and results

• Why are multiple instances of the same vulnerability reported for a single server?

  Application vulnerability detection targets specific running process instances. If a server runs multiple instances of a process with the same vulnerability, such as two identical Tomcat services on different ports, the system reports a separate vulnerability for each instance. If the vulnerable software is installed but its corresponding process is not running, the vulnerability is not detected.

• Why do scan results for vulnerabilities like Fastjson sometimes vary?

  The detection of such vulnerabilities depends on whether their components, such as JAR packages, are loaded into a "runtime" state during the scan. In a dynamic loading model, the system identifies the vulnerability only when business logic calls the vulnerable component. Therefore, scan results may differ at different times.

  Note

  To improve detection accuracy for these types of vulnerabilities, we recommend that you run periodic or multiple scans.

• Why do vulnerability records for a host remain on the console after its agent goes offline?

  When an agent goes offline, its previously detected vulnerability records are retained on the console. However, these records automatically become stale, and you cannot act on them (for example, remediate, verify, or delete them). Vulnerabilities automatically become stale after the following periods:

  Important

  All data is permanently deleted only if the Security Center service expires and is not renewed within 7 days.

  • Linux Software Vulnerability and Windows System Vulnerability: 3 days.

  • Web-CMS Vulnerability: 7 days.

  • Application Vulnerability: 30 days.

  • Urgent Vulnerability: 90 days.

• Will a manual scan affect the automatic scanning schedule?

  Running a manual one-click scan does not affect the existing automatic scan schedule. The two operate independently. Automatic scans, such as system vulnerability scans that run daily or every two days, continue on their scheduled cycles regardless of manual scans.

Scan behavior and results

• Why is the number of emergency vulnerabilities different from the number of application vulnerabilities?

  Emergency vulnerabilities are confirmed by Alibaba Cloud security engineers and detected by version comparison and POC verification. They are displayed only on the Emergency Vulnerabilities tab. Application vulnerabilities are automatically detected through Software Composition Analysis (SCA), targeting process instances and involving components such as Apache, Redis, and Docker. The two types differ in detection mechanism, display location, and fix method, so their counts do not correspond exactly. Even if detection rules are based on the same version number (such as fastjson < 1.2.83), results may differ due to the runtime loading state of components.

Performance impact and security

• Do vulnerability scans or POCs for urgent vulnerabilities affect business systems?

  Typically, no. The POCs from Security Center send only one or two harmless probe requests and do not perform any attacks or destructive actions. However, in rare cases where an application handles unexpected input poorly, a minimal, unknown risk might exist.

• Why can a vulnerability scan trigger an out-of-memory (OOM) error?

  The Security Center agent has a default memory limit of 200 MB. If memory usage during a scan exceeds this limit, the system's OOM mechanism terminates the detection process (ALiSecCheck) to conserve resources.

  Note

  • This limit is typically managed by a control group (cgroup) named aegisRtap0. You can find related OOM information in the dmesg logs.

  • This is normal behavior and does not indicate a system-wide memory shortage. No user intervention is required.

  • This type of Out of Memory (OOM) error results from a cgroup memory limit, not a system-wide memory shortage.

Scan scope and capabilities

1. What does the vulnerability scan cover?

   Scanning covers both the system and application layers:

   • System layer: Linux Software Vulnerability and Windows System Vulnerability.

     Important

     Windows System Vulnerability scanning supports only monthly security update patches.

   • Application layer: Web-CMS Vulnerability, Application Vulnerability, and Urgent Vulnerability.

2. Can I use Security Center for vulnerability scanning during an attack-and-defense exercise?

   Yes. Before an attack-and-defense exercise, you can use Security Center vulnerability scanning to check your assets. Vulnerability scanning covers the following types:

   • Linux Software Vulnerability

   • Windows System Vulnerability

   • Application Vulnerability (requires the Enterprise or Ultimate edition)

   • Urgent Vulnerability

   Risky configurations of cloud services are not covered by vulnerability scanning. These risks are detected by Cloud Platform Configuration Assessment (Cloud Security Posture Management, CSPM).

   Security Center vulnerability scanning does not cover code logic vulnerabilities, such as business logic bypass or privilege escalation issues that require understanding business semantics. If you need to detect code logic vulnerabilities during an attack-and-defense exercise, use the Penetration Test service, which is independent from vulnerability scanning.

3. 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 Vulnerabilities > Vulnerabilities. In the overview section, find the Disclosed Vulnerabilities card.

   3. Click the total number of vulnerabilities on the card to view a list of all detectable vulnerabilities and their details.

4. Is detection for specific vulnerabilities like Elasticsearch supported?

   Yes. You can view detection results for services like Elasticsearch on the Application Vulnerability page in the console.

   Note

   This feature is available only for Subscription (Enterprise and Ultimate editions) and Enable Pay-as-You-Go Service (Comprehensive Host Protection and Hosts and Container Protection). If your current edition does not support this feature, upgrade your service.

Scan scope and capabilities

• Does Security Center alert on unlisted CVE vulnerabilities?

  Security Center only alerts on known vulnerabilities listed in its vulnerability database. If a CVE number has not been officially disclosed or listed (such as undisclosed numbers like CVE-2026-31431), the system cannot identify the risk and does not send alerts. If a vulnerability has been disclosed with a patch available but is still not detected, verify whether you have manually fixed it or taken mitigation measures. Follow Alibaba Cloud security announcements. After the vulnerability is officially disclosed and the vendor releases a patch, Security Center updates detection rules and supports scanning.

• Where can I view the latest classification after vulnerability rule categories are adjusted?

  Some vulnerability rules may be removed from the application vulnerability category due to false positives and adjusted to be supported as system vulnerabilities. You can find the latest classification in the Disclosed Vulnerabilities list.

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

  Security Center supports manual vulnerability scanning. Major Linux distributions are generally within the supported range. For the support status of specific OS versions such as Ubuntu 24.04, refer to the actual scan results in the console. The following methods are supported:

  • Log on to the console and go to Risk Management > Vulnerabilities, select the region where your assets are located in the upper-left corner, click Quick Scan and select the vulnerability types.

  • On the Asset Center > Host page, select the target servers and click Security Check below the list to perform vulnerability scanning.

• Why are emergency vulnerabilities not in the Vulnerabilities to Fix (CVE) list?

  Urgent Vulnerability and High-priority Vulnerabilities (CVE) are classifications of different dimensions. It is normal that they are displayed independently:

  • Urgent Vulnerability: High-risk vulnerability types confirmed by Alibaba Cloud security engineers. These are mostly application or middleware vulnerabilities (such as Fastjson and Apache Dubbo), which are usually related to business code or configurations. They do not support one-click fix and are displayed only on the Urgent Vulnerability tab, where you can detect and ignore them.

  • High-priority Vulnerabilities (CVE): A statistical dimension in the vulnerability management overview. It is filtered based on vulnerability risk scores and includes only system-level vulnerabilities that support one-click fix (such as Linux kernel and system components, and Windows system components).

  The two types of vulnerabilities have different fix methods (one-click fix vs. detection-only with manual handling) and are displayed separately in the console. Emergency vulnerabilities are not included in the High-priority Vulnerabilities (CVE) list.

• How do I stop automatic scanning of emergency vulnerabilities?

  Log on to the Security Center console. Go to Risk Governance > Vulnerabilities, click Vulnerability Management Settings in the upper-right corner of the page, find Urgent Vulnerability Scan Cycle, and change the cycle to Stop to disable periodic automatic scanning of emergency vulnerabilities. This option is available only when a scan cycle task exists.

  Application Vulnerability Scan Cycle provides only Every 3 Days, Every 1 Week, and Every 2 Weeks. It does not have a stop scanning option. Therefore, you cannot stop automatic scanning of application vulnerabilities through this configuration. To reduce the scanning frequency, change the cycle to Every 2 Weeks.

  Stopping or reducing the frequency of automatic scanning reduces the timeliness of vulnerability discovery. We recommend that you keep necessary periodic scans or perform Scan.

Scan behavior and results

• Why do Security Center scan results differ from third-party security software (such as Huorong)?

  Security Center mainly detects official patches released periodically by Windows (such as cumulative updates KBxxxxx). Third-party security software such as Huorong may not cover such system-level patches or may use different detection strategies. Therefore, result differences are normal.

• Why does Security Center not detect vulnerabilities that third-party scanning tools (such as Qualys) or manual checks report?

  Third-party security scanners typically determine vulnerabilities by comparing software version numbers with the CVE database (such as CVE-2020-15778). However, some vulnerabilities have no actual impact or require specific conditions to trigger. Security Center detects vulnerabilities based on security announcements from operating system vendors, which differs from third-party scanner strategies. Common reasons are as follows:

  • The distribution vendor fixes the vulnerability through backporting without changing the version number: Security Center identifies it as fixed and does not alert. Third-party scanners based on version comparison produce false positives.

  • Vulnerabilities confirmed and fixed by the distribution vendor with stable update packages: Security Center supports detection and fixing.

  • Vulnerabilities in software that the OS vendor does not fix or user-installed software: Detection is not supported.

  • The kernel version already meets the fix requirements: Third-party tools may use older rule sets for version comparison, while the actual kernel version on the server is already higher than the required fix version. In this case, Security Center correctly determines no vulnerability. We recommend that you run uname -r to verify the current kernel version and compare it with the fix version required by the vulnerability announcement.

  • Vulnerability exploitation conditions are strict or the actual risk is manageable: For some vulnerabilities (such as OpenSSH CVE-2020-15778), exploitation requires the attacker to already have SSH logon access. In scenarios where the server is not exposed to the public network and the actual risk is low, Security Center does not include them in routine scanning based on the actual exploitable risk. To completely eliminate potential risks, refer to third-party recommendations for manual software upgrade.

  • Specific system vulnerabilities are not listed or detection strategies differ: Some distributions release security announcements with their own IDs. If the affected packages are not installed on the asset, the corresponding vulnerabilities are not detected. Some fixes do not have corresponding CVE numbers and are non-standard CVE vulnerabilities outside the CVE-based detection scope. Verify the actual software installation status and follow Alibaba Cloud security announcements.

  • Application 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, the vulnerability is not detected.

• Why do inactive instances still report high-risk vulnerabilities?

  Possible causes include:

  1. Historical assets (instances or snapshots not fully released).

  2. Associated resource risks (such as configuration weaknesses in other cloud products like OSS and RDS).

  3. Data synchronization delay.

  If the alert status shows Passed, no active risk exists and you can ignore it.

• Why do many historical vulnerabilities appear and affect the security score after I turn off the Show Only Real Risk Vulnerabilities switch?

  Application vulnerabilities may have been detected previously but were hidden because the switch was enabled. After you turn off the switch, historical vulnerabilities are displayed and the security score is refreshed. 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. Historical vulnerability records that have expired and been cleared are not reloaded.

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

  In Security Center vulnerability scan results, items marked as Web Scanner are from active scanning (verification through probe requests sent via public IP addresses). We recommend that you fix these first. Items marked as Software Composition Analysis are from passive detection (comparison based on local software version information collected by the agent).

• Why does the application vulnerability detection result not show the specific file path?

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

• Do Security Center vulnerability scan results overwrite historical data?

  Yes. After a vulnerability scan is complete, the results are automatically updated (overwritten) on the asset details page in the console. You can log on to the Security Center console. In the left-side navigation pane, choose Risk Governance > Vulnerability Management to view the latest results. You can also click Task Management in the upper-right corner to view the scan task execution status and details.

• Why does a newly purchased ECS instance have vulnerabilities?

  The OS images used by ECS have a specific version of software packages pre-installed. Linux and Windows vendors continuously release security patches, but images cannot be updated in real time with the latest patches. Therefore, newly purchased ECS instances may have some recently disclosed system component vulnerabilities (such as security updates for kernel, Python, and OpenSSL). This is normal. In addition, software that you install after purchase may also introduce known vulnerabilities.

  You can fix vulnerabilities in the following ways:

  • Security Center paid edition (Enterprise or above): Log on to the Security Center console. On theRisk Governance > Vulnerabilities page, select the vulnerabilities to fix, and click Fix for one-click fix.

  • Security Center Free edition: Manually log on to the ECS instance and perform a system update through the OS package management tool (such as yum or apt).

  Before fixing vulnerabilities, we recommend that you back up system disk data through ECS snapshots to avoid compatibility issues during the fix process.

• Why is there a significant difference in vulnerability alert counts between two servers?

  • Different OS versions and maintenance status: Servers running EOL systems (such as CentOS 5 and Ubuntu 12) continue to report high-risk vulnerabilities because vendors no longer release security updates. These vulnerabilities cannot be eliminated through one-click fix. Servers running systems still within the official support cycle do not have such alerts. For more information, see the EOL section in this topic.

  • Different application process running status: Application vulnerability detection targets running process instances. If one server runs specific middleware or databases and the other does not, the former detects application vulnerabilities for those components while the latter does not.

  In addition, differences in installed software packages, Security Center edition authorization, and vulnerability scan level configurations between the two servers also cause alert count differences.

• What do I do if an alert reports middleware vulnerabilities such as Redis, but I cannot find the corresponding cloud product instance?

  Such vulnerability alerts usually point to middleware installed on ECS servers (such as self-managed Redis), not Alibaba Cloud managed database instances. Security Center detects vulnerabilities on host and container assets, not within managed database instances. We recommend that you use the IP address or hostname in the alert details to locate the corresponding ECS server, and then verify the middleware installation and running status on that server. After locating the middleware, refer to the vulnerability fix documentation for the corresponding middleware to manually upgrade it. After the upgrade, return to the console and click Verify.

• Why am I prompted that high-risk system vulnerabilities are not fixed?

  This prompt indicates that the OS or installed software on the ECS instance has high-risk vulnerabilities that have been officially disclosed but not yet patched. Common causes include: the system image is not updated in time, manually installed software versions are too old, or the status is not updated because the server was not restarted or verified after fixing. Solution: Go to Risk Governance > Vulnerabilities, view vulnerability details by severity, fix vulnerabilities that support one-click fix, and manually handle other vulnerabilities based on announcements. Also make sure that the scan level in Vulnerability Management Settings Vulnerability Scan Level covers the high-risk level.

• What do I do if Vulnerability Management and security alerts have no data after I add a new instance?

  Newly added instances have a time gap between data synchronization and the first scan. The vulnerability management page may not show data immediately. We recommend that you click Scan on the vulnerability management page, select vulnerability types as needed to trigger detection, and view the results after the scan is complete. You can view the scan progress in Task Management. If no data is available after the scan is complete and the agent is online with normal instance status, the instance currently has no detected risks, which is normal. Also make sure that the region selected in the upper-left corner of the console matches the actual region of the asset.

Remediation limitations and principles

• Why is the Fix button grayed out?

  • Issue: Product edition limitations

    • Cause: The one-click fix feature is not supported in Basic Edition or Anti-virus Edition.

    • Resolution: Purchase the "Vulnerability Fixing" value-added service, or upgrade to Enterprise Edition or Ultimate Edition.

  • Issue: Server-side problems

    Linux server issues

    • The operating system has reached its end-of-life (EOL): The vendor no longer provides patch. You must manually upgrade the operating system. Fixing vulnerabilities in the following operating systems requires an OS upgrade:

      • Red Hat 5, Red Hat 6, Red Hat 7, Red Hat 8

      • CentOS 5

      • Ubuntu 12

      • Debian 8, 9, 10

    • Insufficient disk space: The available disk space is less than 3 GB. Free up space or expand the disk.

    • Process in use: The apt or yum process is running. Wait for the process to finish and then retry, or manually terminate the process.

    • Insufficient permissions: The user running the remediation command does not have sufficient permissions. Ensure that the file owner is the root user and set appropriate permissions, such as 755.

    Windows server issues

    • Insufficient disk space: The available disk space is less than 500 MB. Free up space or expand the disk.

    • Windows Update service is not working as expected: The service is disabled or a patch installation is already in progress.

      • If the service is disabled, go to the Services manager on the server, enable the Windows Update service, and then try fixing the vulnerability again.

      • If an update is in progress, wait for the Wusa.exe process to complete or manually end the process, and then try fixing the vulnerability again.

• What is the difference between an application vulnerability and a system vulnerability? Why doesn't one-click fix support application vulnerabilities?

  • A system vulnerability, such as a Linux software vulnerability or a Windows system vulnerability, affects the operating system or its components. These vulnerabilities have standardized remediation paths, which allows them to be fixed with the one-click fix feature.

  • An application vulnerability exists in a self-managed application, such as website code or third-party software. The remediation method for this type of vulnerability is closely tied to your specific business logic and code. Because automated tools cannot understand your business context, you must remediate these vulnerabilities manually.

• Why does my server have so many vulnerabilities? 

  As new attack methods emerge, vulnerabilities are continuously discovered in older software. Regular scanning and patching are essential and ongoing security tasks. To help you focus on the most critical risks, turn on the Show Only Exploitable Vulnerabilities switch.

Remediation operations

• What should I do if the error "Permission acquisition failed, please check permissions and retry" appears when I run a fix command?

  • Cause: The owner of the file required to perform the repair operation is not root, which results in insufficient permissions.

  • Resolution:

    1. Locate the file:

       In Security Center, view the vulnerability details to identify the specific file and path that require remediation.

    2. Modify permissions:

       Log in to the server and run the following command to change the file owner to root.

    3. Retry the fix:

       Return to the Security Center console and run the remediation operation on the vulnerability again.

• When I fix vulnerabilities in a batch, in what order are they fixed?

  Linux software vulnerability is fixed in the order they appear in the console list. Some Windows system vulnerabilities require prerequisite patch to be installed first. When you run a batch fix for Windows system vulnerabilities, these types of vulnerabilities are prioritized. The remaining vulnerabilities are fixed in the order they appear in the console list.

• Why does a restart not work after I fix a kernel vulnerability on Ubuntu?

  • Symptom: After you use the one-click fix feature in Security Center to patch a kernel vulnerability on an Ubuntu server, a "Fixed, pending restart" message is displayed. However, after you restart the server, the vulnerability alert persists because the system does not use the newly installed kernel.

  • Cause: This issue typically occurs if the default boot order of the GRUB boot menu was manually modified. The remediation script is then unable to set the new kernel as the default boot option.

  • Resolution:

    Solution 1: Automatically configure new kernel

    This solution discards your existing custom GRUB configuration and allows the system to automatically apply the default settings for the new kernel.

    Procedure:

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

    2. Run the following command to set the environment variable:

       <BASH>
       
       export DEBIAN_FRONTEND=noninteractive

    3. Return to the Security Center console and perform a one-click fix on the vulnerability.

    4. After the fix is complete, restart the server as prompted. The system automatically enables the latest kernel.

    Solution 2: Manually modify boot order

    If you need to keep your existing GRUB configuration, you can use this solution.

    Procedure:

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

    2. After the server restarts, log on to your Ubuntu server.

    3. Manually modify the GRUB boot order to set the newly installed kernel version as the default boot option.

       Note

       The procedure usually involves modifying the /etc/default/grub file and running the update-grub command. For more information, see Change the kernel boot order of an ECS Linux CentOS instanceChange the kernel boot order of an ECS Linux CentOS instance.

    4. Restart the server again for the new boot order to take effect.

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

  • Windows: A restart is required.

  • Linux Software Vulnerability: A restart is required if either of the following conditions is met:

    • A kernel vulnerability was fixed.

    • On the Linux Software Vulnerability tab of the Risk Governance > Vulnerabilities page in the Security Center console, the bulletin for the vulnerability has a Restart Required tag.

• Why does a vulnerability rollback operation fail?

  If a vulnerability rollback operation fails, investigate the following possible causes:

  1. Check the agent status

     The rollback operation requires the Security Center agent to be online. If the agent is offline, the command cannot be delivered. You must first troubleshoot and resolve the agent's offline status.

  2. Confirm that the backup snapshot is valid

     The rollback feature relies on the backup snapshot that was created before the remediation. If the snapshot has expired or was manually deleted, the rollback operation cannot be performed.

• Why does snapshot creation fail when I fix a vulnerability?

  Creating a snapshot may fail for the following reasons:

  • Operation performed by a RAM user: If a RAM user without the required permission performs the operation, snapshot creation fails. We recommend that you use your Alibaba Cloud account to perform the operation. For more information about RAM user, see Overview.

  • Non-Alibaba Cloud server: Snapshot creation for vulnerability remediation is not supported on non-Alibaba Cloud server.

Post-remediation status and verification

• I fixed a vulnerability, but Security Center still reports it. What should I do?

  • Cause: This issue occurs because some vulnerabilities, such as Linux kernel vulnerabilities, require a server restart after remediation.

  • Resolution: On the vulnerability details page, click Restart. After the restart is complete, click Verify. If the status changes to Repaired, the vulnerability is successfully fixed.

• I fixed a vulnerability without upgrading the software version, but Security Center still reports it. What should I do?

  • Cause: Security Center detects Application Vulnerability and Urgent Vulnerability by comparing the version number of the software or component. If you mitigate a vulnerability instead of upgrading to a secure version, for example, by enabling SafeMode in fastjson to disable AutoType, the version number remains within the affected range. Subsequent scans continue to report the vulnerability, and clicking Verify does not change the status to fixed.

  • Resolution: After you confirm that the mitigation has eliminated the risk, go to the Vulnerabilities page and apply Ignore or Add to Whitelist to the vulnerability to stop repeated alerts. Ignore takes effect only for the current process. If the application restarts or a new process starts, Security Center may detect the vulnerability again. Add to Whitelist suppresses alerts for this type of vulnerability within the configured scope until you manually delete the whitelist rule. For the differences between the two actions and the corresponding procedures, see the "Defer remediation" section of this topic.

• Why does the status of Windows vulnerability fixes change to "Invalid"?

  The Windows vulnerability detection mechanism has been updated. Following monthly updates to Windows vulnerability rules, the status of existing vulnerabilities affected by these rule changes will be marked as "Invalid."

• After I fix a vulnerability, why does the console still show a "Not fixed" status? 

  This may occur for the following reasons:

  1. Verification delay: After a manual fix, you must click the Verify button to trigger an immediate scan. The status update may take a few minutes.

  2. Browser cache: The console page may be cached in your browser. Try force-refreshing the page or waiting a few minutes.

  3. Incomplete fix: The remediation operation may not have been fully successful. For example, a vulnerability may have multiple vulnerable paths, but only one was fixed. Review the remediation steps and try again.

• Fixed and Pending Restarted: Can Security Center automatically verify a vulnerability in this state?

  No. You must restart the server from the Security Center console or restart it manually. After the server restarts, click Verify to confirm that the vulnerability is fixed.

  Important

  If you do not manually verify the fix, Security Center automatically checks the status during the next scheduled scan. To prevent false negatives from network issues, the system retains the vulnerability record for three days if it is not detected in the first scan. If the vulnerability remains undetected for three consecutive days, the system removes the record.

• Why does the verification status not update after I manually fix a vulnerability?

  After you manually fix a vulnerability on a server, if the 'Verify' feature in the Security Center console fails to update the vulnerability's status to 'Fixed', this issue usually occurs for the following two reasons:

  • The vulnerability scan level is not fully configured

    • Cause: Security Center scans and updates the status only for the risk levels selected in Vulnerability Settings. If the risk level of the target vulnerability, such as High or Medium, is not selected, the system does not update its status.

    • Resolution: Check the scan settings in Vulnerability Settings and ensure that the risk level of the target vulnerability is selected.

  • The Security Center agent is offline

    • Reason: The 'Verification' function relies on real-time communication between the console and the client on the server. If the client is offline, the console cannot send verification commands or receive the results.

    • Resolution: Troubleshoot the offline agent issue. After the agent is back online, try verifying again.

Fix limitations and principles

• After the OS is end of life (EOL), does Security Center support vulnerability scanning and fixing?

  For system versions that are no longer officially supported, such as CentOS 7.6, Security Center does not support vulnerability scanning or one-click fix. If no vulnerabilities are detected by scanning, you need to confirm whether the system version is within the supported range. If not, we recommend that you check the kernel release time or refer to official announcements. You can upgrade the OS to a version still within the official support cycle, or after evaluating and confirming the risk is manageable, mark the vulnerability as Ignore in the console.

• When multiple services are deployed on the same server, what is the impact scope of system vulnerabilities?

  When multiple services are deployed on the same server, system vulnerabilities affect all services on the server because they share the same OS environment. We recommend that you apply system patches to the entire server and make sure to create snapshot backups before fixing.

• Do I need to restart the server when fixing vulnerabilities? What is the impact on business?

  • Windows system vulnerabilities: A server restart is required for the patch to take effect. Restart causes a brief service interruption. We recommend that you fix vulnerabilities during off-peak hours and select Create Snapshot and Fix for rollback.

  • Linux kernel vulnerabilities: A restart is required. If the status is still Fixed - Restart Required after fixing, click Restart in the console or manually restart the server, and then click Verify.

  • Linux software vulnerabilities: A restart is usually not required, unless the vulnerability announcement contains the Restart Required tag.

  • Business impact: Restart causes service interruption, and the fix process may consume resources and cause slowness. We recommend that you back up in advance (snapshots) and verify in a test environment.

  • Service stop mechanism: Windows system vulnerabilities and Linux kernel vulnerabilities require a restart after fixing to take effect, and the restart causes a brief service interruption. Application vulnerabilities and emergency vulnerabilities only support detection and do not support one-click fix, so they do not cause service stops due to Security Center fix operations. For vulnerabilities that require a restart, the console displays the Restart Required tag. After the fix is complete, the status is displayed as Fixed - Restart Required.

  • Risk of not fixing: Not fixing Windows system vulnerabilities does not affect the normal operation of the system and business, but reduces system security and increases the risk of attacks. We recommend that you evaluate fix priorities based on vulnerability severity and business importance, and take mitigation measures such as access control for vulnerabilities that are not fixed immediately.

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

  • Risk description: If a high-risk local privilege escalation vulnerability (such as CVSS 7.8) is not fixed, attackers can exploit it to steal sensitive files (/etc/shadow, SSH private keys) and obtain the highest privileges, resulting in full control of the server.

  • Mitigation: If fixing is not immediately possible, use security groups to restrict access and strengthen monitoring. However, the fundamental solution still requires fixing.

  • SSL/TLS vulnerability identification: For SSL/TLS protocol information disclosure vulnerabilities (such as CVE-2016-2183), you can ping the domain name to resolve the IP address, use CLB/K8s resources to locate the specific affected nodes, and manually fix them.

• Will I be charged again if I click Fix again after a vulnerability fix fails?

  Security Center vulnerability fixing is billed per fix. Clicking Fix Now consumes one fix credit, and the console fix entry displays the current available remaining fix credits. If a fix fails, clicking Fix again for the same vulnerability does not incur additional charges until the fix succeeds. The entire process is charged as one fix. For specific pricing and billing rules, see the Security Center billing documentation.

• Do I need to wait for the snapshot to complete before fixing? How do I roll back if business is abnormal after fixing?

  • Snapshot timing before fix: If you have manually created a snapshot as a backup, we recommend that you wait until the snapshot status becomes Available before performing vulnerability fixing to ensure the backup is valid. When fixing in Security Center, you can select Create Snapshot and Fix, or select Fix Without Snapshot to save time. The latter does not support snapshot rollback.

  • Rollback after fix: If fixing causes application unavailability or system anomalies, you can find the vulnerability with a successful fix status in the Total Handled Vulnerabilities and click Roll Back to select the snapshot created before fixing for recovery. Rollback is only available for Linux software vulnerabilities and Windows system vulnerabilities that support one-click fix. Non-Alibaba Cloud servers do not support rollback.

  • Rollback failure troubleshooting: Rollback failure is usually caused by the agent being offline or the snapshot being deleted or expired. For details, see the sections about why vulnerability rollback fails and why snapshot creation fails during vulnerability fixing in this topic.

• Can high-risk vulnerability alerts be deleted directly? How do I handle vulnerabilities that do not need fixing or are false positives?

  • Direct deletion is not supported: Security Center vulnerability records are generated based on actual asset detection results and do not support manual deletion. Vulnerability records become invalid only when the agent is offline for longer than the retention period or when the service expires.

  • Recommended action: For vulnerabilities confirmed as non-risky, false positives, or not requiring immediate fixing, use Ignore or add them to the Whitelist to stop alerts.

  • Difference between Ignore and Whitelist: Ignore takes effect on a single vulnerability record on the current asset. If the vulnerable process is restarted or the vulnerability is detected again in subsequent scans, it may reappear. Whitelist configures the scope by vulnerability dimension (all assets, specified asset groups, or specified assets) and remains effective until the whitelist rule is manually deleted.

  • Handling of low-severity vulnerabilities: In pay-as-you-go mode, you can decide whether to fix low-to-medium severity vulnerabilities based on business risk assessment. For vulnerabilities not fixed immediately, use Ignore or Whitelist to manage alert noise.

• Do emergency vulnerabilities showing To Be Protected or Protected need to be handled?

  • Status description: Emergency vulnerabilities only support detection and do not support one-click fix. The Unprotected / Protected in the list indicates the protection status of Cloud Firewall virtual patches:Unprotected indicates that the vulnerability is not yet protected by Cloud Firewall virtual patches. You can click the link to go to the Cloud Firewall vulnerability protection page to enable protection. Protected indicates that Virtual Patching of Cloud Firewall Is Enabled has taken effect. The handling status of emergency vulnerabilities themselves also includes Unfixed, Fix Failed, Fixing, Verifying, Fixed, Ignored, and Expired.

  • Troubleshooting: If the daily report indicates emergency vulnerability risks but the console does not show them, go to Risk Governance > Vulnerabilities > Urgent Vulnerability tab to check for unfixed emergency vulnerabilities, and confirm that the region selected in the upper-left corner matches the asset location.

  • Handling recommendation: A normal protection status does not mean absolute security. We recommend that you upgrade the affected components to secure versions as suggested in the vulnerability details, or use Cloud Firewall virtual patches for protection.

• Application vulnerabilities do not have a process ID. How do I protect them?

  Application vulnerabilities target running process instances for detection. Some application vulnerabilities are not associated with a process ID and do not support one-click fix. You can use the following methods for protection:

  • Upgrade to the vendor version: Go to the software vendor official website to download the latest version and upgrade to fix the vulnerability.

  • Use RASP application protection: Enable Application Protection (RASP) in the Security Center console to provide runtime protection through Security Center integration. This is a paid feature. For more information about its runtime protection capabilities, see What is application protection.

Fix operations

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

  Automatic fixing usually does not cause the server to shut down, but some kernel vulnerability fixes may require a restart. For manual fixing, the requirement depends on the vulnerability type: Linux software vulnerabilities generally do not require a restart, while Windows system vulnerabilities and Linux kernel vulnerabilities require a restart to take effect. We recommend that you fix vulnerabilities during off-peak hours and create snapshots.

• Is the effect of Security Center automatic Windows patch fixing the same as manual patch download and installation?

  Yes. The Security Center fix feature essentially calls system-level interfaces to install official Microsoft patches, which is the same as manual download and installation.

• After Microsoft releases a patch, do I need to wait for Security Center synchronization before fixing?

  No wait is required. You can directly install the latest cumulative update patch through Windows system update on the server to complete the fix. After installation, go to the Security Center console and click Verify for the vulnerability to update the status. If the status is not updated in time, wait for the next periodic scan. The effect of automatic fixing in Security Center is the same as manual installation of official patches. For details, see the section about automatic vs. manual patch installation in this topic.

• Does Security Center support generating and exporting vulnerability scan reports?

  • Application vulnerability report: Pay-as-you-go editions need to be upgraded to Full Host Protection or higher to support application vulnerability scanning. Log on to the console and go toRisk Governance > Vulnerabilities > Application Vulnerability tab. Click the icon above the list to export the application vulnerability list on the server. Note: Independent reports for website URLs are not supported.

  • Specified ECS instance vulnerability information: Go to Asset Center > Host, search for the target server to go to the details page, and click the Vulnerability Details section under VulnerabilitiesApplication Vulnerability list. Click the icon to view and export.

  • Security Report: Go to System Configuration > Security Report to create a custom security report. Security Center does not currently support providing dedicated vulnerability scan reports. To obtain a vulnerability scan report, you can purchaseSecurity Assessment Service to perform vulnerability scanning.

• How do I determine whether a Linux kernel version is affected by a specific CVE vulnerability?

  1. Run the uname -r command to view the current kernel version and compare it with the affected version range in the CVE announcement.

  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 system is not affected and no fix is required.

  3. You can visit the Alibaba Cloud official vulnerability risk and fix announcement page to check specific impacts.

• How do I handle the execution order, concurrency recommendations, and UI display issues during batch vulnerability fixing?

  • Execution order: Linux software vulnerabilities are executed in the console list order. For Windows system vulnerabilities, vulnerabilities that require prerequisite patches are fixed first, and the rest are executed in list order.

  • Concurrency recommendation: We recommend that you wait for the previous batch of vulnerability fixes to complete before executing the next batch to avoid resource conflicts or management confusion.

  • UI not responding: If the UI shows no response after "Sending commands" during batch fixing, it may be a frontend display delay. Manually refresh the page to view the "Fixing" status.

  • Duration: Linux automatic fixing usually takes several minutes to tens of minutes, depending on the number of vulnerabilities, server performance, and network. If it takes too long, check disk space (recommended >= 3 GB), package manager process conflicts, or permission issues.

• Do servers without a public IP address support Security Center vulnerability fixing?

  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 network sources for fixing, no public IP address binding is required. Prerequisites: Make sure that Security Center is activated and the agent is online.

• What are the precautions and recommendations for enabling automatic vulnerability fixing?

  • Not enabled by default: Automatic fixing requires manual policy configuration to take effect and is not enabled by default.

  • Supported scope limitation: Only non-kernel Linux system vulnerabilities are supported, and it depends on the one-click fix feature (version support required).

  • Operation recommendations: We recommend that you verify in a test environment first. Make sure a snapshot backup policy is configured before enabling. Configure execution during off-peak hours. Avoid enabling for all assets to prevent excessive fix credit consumption or resource contention.

• Does fixing database or middleware versions (such as MySQL or Oracle) affect business? What are the precautions?

  • Business impact: The fix process itself does not modify business data in the database, but version upgrades usually require restarting the database or middleware service, which may cause a brief service interruption. We recommend that you fix during off-peak hours.

  • Backup recommendation: Make sure to create an ECS snapshot or database backup before fixing. When fixing in Security Center, you can select Create Snapshot and Fix. If you select Fix Without Snapshot, snapshot rollback is not available after anomalies.

  • Fix priority: Not all vulnerabilities need to be fixed immediately. We recommend that you prioritize urgent and high-severity vulnerabilities. Medium-to-low severity vulnerabilities can be fixed at a scheduled time after evaluating business impact, or you can choose to Ignore them or add them to the Whitelist after implementing mitigation measures (such as restricting access through security groups).

  Database and middleware vulnerabilities are mostly application vulnerabilities and do not support one-click fix. You need to log on to the server to manually upgrade and then return to the console to click Verify.

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

  Troubleshoot in the following order:

  1. Edition authorization check: One-click fix and batch fix depend on Security Center paid editions or paid vulnerability fix capabilities. The free edition does not support one-click fix. Confirm the authorized edition for the target server on the Assets page. Upgrade the edition or enable vulnerability fix capabilities if necessary. For specific support scope, see Fix vulnerabilities.

  2. Filter check: Check whether overly restrictive filters are selected on the Vulnerability Management page, such as the Show Only Exploitable Vulnerabilities switch, vulnerability severity, or handling status. Try clearing the filters and refreshing the page.

  3. Region check: Confirm that the region selected in the upper-left corner of the console matches the actual region of the assets. Region matching is especially important for application vulnerabilities.

  4. Vulnerability type limitation: Confirm whether the selected vulnerabilities support one-click fix. Batch fixing only applies to Linux software vulnerabilities and Windows system vulnerabilities that support one-click fix. Application vulnerabilities and emergency vulnerabilities only support scanning and manual fixing, and do not support batch one-click fix.

• What do I do if vulnerability fixing in an ACK cluster is slow or inefficient?

  • Check fix task configuration: The vulnerability fixing efficiency in container clusters is affected by the concurrency capability of fix tasks. We recommend that you check the relevant configuration of vulnerability fix tasks in the Security Center console to confirm whether the concurrency can be increased.

  • Optimization recommendation: Observe the fix progress after adjustment. If performance bottlenecks still exist, evaluate the cluster node resource load comprehensively to avoid resource contention between fix tasks and business.

  During fixing, you can view specific task progress and failed nodes through Task Management.

• I received a high-risk vulnerability notice from the authority, but access control is already in place. How do I fill in the rectification report?

  • Handling principle: If you confirm that the asset with the vulnerability has strictly restricted access through security groups, network ACLs, and other measures (such as allowing only trusted IP addresses), and immediate fixing is not feasible for business reasons, you can describe the access control configuration as a compensating measure.

  • Report filling: In the rectification report, describe the current vulnerability status and impact scope, the implemented access control policies (with configuration screenshots), the risk assessment conclusion, and the subsequent fix plan and schedule to prove that the risk is under control.

  • Follow-up actions: Compensating measures do not replace fixing. We recommend that you complete vulnerability fixing during a business window and update the vulnerability status through verification after fixing.

• How do I disable automatic vulnerability fixing to avoid additional charges?

  On the Vulnerability Management page, click Vulnerability Management Settings in the upper-right corner, go to the Automatic Vulnerability Fix Settings tab, and turn off the Automatic Vulnerability Fix Switch. After disabling, fix tasks are no longer automatically executed, and no fix credits are consumed by automatic fixing. Before disabling, we recommend that you confirm the configured automatic fix policy scope to avoid affecting existing O&M arrangements. The automatic fix card on the Security Center Overview page is only used to enable this feature and redirect to the settings tab. To disable it, go to Vulnerability Management Settings.

Fixing specific vulnerability types

• How do I handle the situation where Security Center still reports vulnerabilities after a kernel upgrade fix?

  1. Confirm that the current kernel is upgraded successfully

     1. Check the currently running kernel version and make sure it meets the requirements specified in the vulnerability description.

        uname -av
        cat /proc/version

     2. Confirm that the system boots with the new kernel

        <BASH>
        
        cat /etc/grub.conf

  2. Check and clean up old kernel rpm packages

     1. View all installed kernel packages and identify old kernel packages (versions lower than the current kernel).

        rpm -qa | grep kernel

     2. Create a protective snapshot for the system (strongly recommended)

        Create a snapshot/image for the current instance in the ECS console to prevent system anomalies or boot failures caused by accidental deletion.

     3. Uninstall old kernel rpm packages

        2. <BASH>
           
           rpm -e kernel-<old_version>

        3. Or use the distribution-recommended method:CentOS/RedHat：

           <BASH>
           
           yum remove kernel-<old_version>

  3. Ignore the alert

     After confirming that the new kernel in use has fixed the vulnerability, ignore the alert only.

     1. Log on to Security Center console.

     2. In the left-side navigation pane, choose Risk Governance > Vulnerabilities. In the upper-left corner of the console, select the region where the asset to be protected is located: Chinese Mainland or Outside Chinese Mainland.

     3. Click the Linux Software Vulnerability tab to locate the vulnerability, and click the vulnerability name to go to the Vulnerability Details page.

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

• How do I manually upgrade the Ubuntu kernel?

  Important

  Kernel upgrades involve certain risks. We strongly recommend that you refer toFix software vulnerabilitiesfor the upgrade method.

  The following example describes how to manually upgrade the Ubuntu kernel from 3.1* to 4.4 on Ubuntu 14.04.

  1. Run the uname -av command to check whether the current kernel version is 3.1*.

     root@iZbp14z5cmxxxf76owZ:~# uname  -av
     Linux iZbp14z5cmxxxf76owZ 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

  2. Run the following commands to check whether the latest kernel update packages are 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 updates are available, run theapt-get update command to get the latest update packages.

  4. Run the following commands to upgrade the kernel.

     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. After the update packages are installed, restart the server to load the new kernel.

  6. After the server restarts, run the following commands to verify whether the kernel upgrade is successful.

     • Run the uname -av command to view the current kernel.

       root@iZbp14z5cmxxxxf76owZ:~# uname -av
       Linux iZbp14z5cmxxxxf76owZ 4.4.0-94-generic #117~14.04.1-Ubuntu SMP Wed Aug 30 06:50:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

     • Run the dpkg -l | grep linux-image command to view the current kernel packages.

       Also run uname -av to confirm that the current kernel version is 4.4.0-94-generic. In the output, linux-image-4.4.0-94-generic and linux-image-extra-4.4.0-94-generic are the kernel packages in use.

       root@iZbp14z5cm****f76owZ:~# uname -av
       Linux iZbp14z5cm****f76owZ 4.4.0-94-generic #117~14.04.1-Ubuntu SMP Wed Aug 30 06:50:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
       root@iZbp14z5cm****f76owZ:~# dpkg -l | grep linux-image
       ii  linux-image-3.13.0-32-generic        3.13.0-32.57             amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-3.13.0-65-generic        3.13.0-65.106            amd64        Linux kernel image for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-4.4.0-94-generic         4.4.0-94.117~14.04.1     amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
       ii  linux-image-extra-3.13.0-32-generic  3.13.0-32.57             amd64        Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-extra-3.13.0-65-generic  3.13.0-65.106            amd64        Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
       ii  linux-image-extra-4.4.0-94-generic   4.4.0-94.117~14.04.1     amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
       ii  linux-image-generic                  3.13.0.65.71             amd64        Generic Linux kernel image

• What do I do if I receive a target kernel incompatibility error when fixing a kernel vulnerability?

  • Symptom: After one-click kernel vulnerability fix in the Security Center console, the fix fails and the error message shows target kernel incompatibility.

  • Cause: The system detects that the kernel version on the server is incompatible with the target fix version. This may be caused by manual kernel configuration changes, non-standard kernel versions, or a large kernel version gap that prevents normal upgrade.

  • Solution:

    • Method 1: Use force fix

      If you confirm that business is not affected, use force fix to skip the compatibility check:

      1. Close the fix failure dialog.

      2. In the Unhandled Vulnerabilities area, click the target server Actions column's Fix button.

      3. In the fix dialog, the Mandatory Fix option appears. After selecting this option and the fix method, click Fix Now to retry.

         Important

         Fixing vulnerabilities may involve upgrading the system kernel or software version, which has business compatibility risks. We recommend that you select the Automatically Create Snapshot and Fix Risk option for quick rollback if issues occur.

    • Method 2: Manually upgrade the kernel

      If force fix is not suitable, refer toUpgrade Linux ECS instance kernelfor manual upgrade.

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

  • Use cases: Force fix is mainly used in the following scenarios:

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

    • When the current system environment meets the vulnerability fix requirements but the compatibility check fails.

  • Operation method: In the fix dialog, select the Mandatory Fix option.

  • Risk warning: Force fix skips the client compatibility check and may have the following risks:

    • After fixing, the system may have compatibility issues that cause business anomalies.

    • Kernel upgrade failure may prevent the system from booting properly.

  • Recommendation: Before using force fix, select the Automatically Create Snapshot and Fix Risk option to create a backup for quick rollback. Force fix is recommended only when you confirm that business is not affected.

• What do I do if some vulnerabilities in the Security Center console show no updates?

  No updates for a vulnerability means that the software with the vulnerability has no official update source and cannot be fixed in the Security Center console. Refer to the following instructions and choose an appropriate solution:

  • Official update source has not provided a patch

    • Symptom: When running the update command, the system returns already installed and latest version or No Packages marked for Update or similar messages.

    • Known packages: Gnutls, Libnl, MariaDB

    • Recommendation: Wait for the official source to release an update.

  • The OS version is no longer supported (EOL)

    • Symptom: Even if the package is the latest version supported by the current system, it still does not meet the version required for vulnerability fixing. For example, CentOS 6.x and other EOL system versions.

    • Recommendation:

      • Method 1: Upgrade the OS to a version still within the official support cycle.

      • Method 2: After evaluating and confirming the risk is manageable, mark the vulnerability as“Ignore”。

  • Rescan: On the vulnerability management page, run Scan again to get the latest detection results and fix solutions.

  • Wait for sync: If no fix option is available after scanning, the official patch may not be released yet or the fix solution is still being verified. Wait for subsequent updates.

  • Alternative: If a vulnerability has no fix option for a long time, refer to the OS vendor's official security announcement for manual handling, or take temporary mitigation measures such as access control. After evaluating the risk, perform Ignore.

Post-fix status and verification

• After running yum update kernel, Nothing to do or no upgrade success message, do I need to restart the server?

  Even if yum update kernel returns Nothing to do, or no upgrade success message is displayed, we still recommend a restart to ensure the kernel change takes full effect and the system running state is consistent with the installed kernel. After the restart, click Verify on the vulnerability details page in the Security Center console to check whether the vulnerability status is updated to Fixed. If the status is still not updated after verification, refer to the troubleshooting instructions in this section.

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

  • Viewing method: In the Security Center console, on the Vulnerabilities page, click the number under Fixing panel. Find the vulnerability with a failed fix, click the Fixing column's Status column's icon, and then view the fix failure alert in the Cause Details dialog.

  • Alert content: The fix failure alert shows the specific cause of the failure, the corresponding error code (if any), and handling recommendations.

• How do I handle error codes in fix failure alerts?

  Based on the error code in the fix failure alert, refer toTroubleshoot causes of vulnerability fixing failuresfor the corresponding solution.

• Does manual vulnerability fixing 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. The two are unrelated. If the console still shows the vulnerability as unfixed after manual fixing, click the Verify button or wait for the subsequent automatic status update.

• Why does a vulnerability still show as unfixed or restart required after fixing, or why does verification not respond?

  • Restart required status: For Linux kernel vulnerabilities or vulnerabilities marked with Restart Required, a server restart is required after fixing. You can click Restart directly on the Security Center vulnerability details page (only available for Fixed - Restart Required Linux software vulnerabilities and Windows system vulnerabilities. Non-Alibaba Cloud servers are not supported). Alternatively, log on to the ECS console or server and run the rebootcommand. After the restart, click Verify to update the status.

  • Unified restart for multiple vulnerabilities: Multiple vulnerabilities that require a restart can be fixed one by one to install patches, and then the system can be restarted once at the end. You do not need to restart for each vulnerability.

  • Verification not responding: If the status does not change for a long time after clicking Verify, it may be caused by incomplete vulnerability scan level configuration or agent offline status. For details, see the section about why manual verification does not respond after fixing.

  • Data synchronization delay: After ignoring a vulnerability or completing a fix, the console display may have a delay, which is normal. Wait for automatic synchronization or manually trigger verification.

• Why are vulnerabilities detected even though I did not actively install third-party software?

  Third-party software vulnerabilities detected by Security Center may come from pre-installed components in system images or their dependency libraries, and are detected even if you did not actively install the software. For more information, see the section about why newly purchased ECS instances have vulnerabilities. We recommend that you view the impact description and file path in the vulnerability details to confirm the specific file that triggered the alert. If it is confirmed as a false positive or does not need fixing after evaluation, you can perform Ignore on the vulnerability, or add it to a whitelist based on the vulnerability type.

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

  Rule Offline is one of the handling reasons for application vulnerabilities, indicating that the detection rule has been taken offline and the vulnerability will no longer be identified as an application vulnerability. Other parallel reasons include Process Not Exist, Middleware Not Exist, and Middleware Updated. No additional action is required when this mark appears.

• Why are vulnerabilities found in the /usr/share/doc directory? Will the same vulnerabilities reappear after fixing?

  • /usr/share/doc vulnerability cause: Files in this directory are mostly basic component documentation or example files that come with the system image. The component versions recorded in these files are low and match known vulnerabilities in the vulnerability database, which triggers alerts. This is normal detection behavior. To eliminate alerts, upgrade the component version or add it to a whitelist after confirming no actual runtime risk.

  • Vulnerability recurrence cause: Vulnerability fixing only patches the version detected in the current scan. If subsequent system or application updates introduce new vulnerabilities, configurations change, or security best practices are not followed, new vulnerability records may still be detected.

  • Continuous protection recommendations: We recommend that you regularly perform vulnerability scans, follow official security announcements, and combine baseline checks to harden the system, rather than relying on one-time fixes.