# Scaneo AI Remediation Plan Domain: example-company.com Website: https://www.example-company.com/ Reference ID: demo-2026 Generated: 2026-06-24 10:00 UTC ## Important This is a public demo document built from anonymized sample data. It is not a scan of a real customer. These prompts are designed to help developers, administrators and AI coding tools understand and plan remediation. Do not apply AI-generated changes blindly. Review all suggestions before implementation. Test changes outside production where possible. Verify the result after remediation. Some findings require human judgement and cannot be fixed automatically. --- ## Summary Total findings: 18 Verified findings: 9 Unverified findings: 9 Each finding below includes: status, CVSS, area, affected asset, responsible person, estimated manual effort, AI suitability, summary, current recommended solution, recommended fix steps, AI remediation prompt, and references. --- ## 1. SQL Injection indication Status: Unverified CVSS: 8.8 Area: backend Affected asset: app.example-company.com Responsible person: Backend developer Estimated manual effort: 2–4 hours AI suitability: Medium — AI tools can help review the code path, but verifying and fixing injection-prone queries requires careful manual review. Summary: An automated scan returned a response pattern consistent with possible SQL injection on a search or query parameter. This finding is unverified and requires manual confirmation. Current recommended solution: Manually review the affected endpoint, confirm whether user input reaches a database query, and apply parameterized queries or a safe ORM API. Recommended fix steps: 1. Manually confirm the finding before making any changes — do not assume exploitation succeeded. 2. Trace the affected parameter through the codebase to where it reaches the database layer. 3. Replace string-concatenated queries with parameterized queries or a safe ORM API. 4. Add input validation as a defense-in-depth measure. 5. Re-test with the original scanner and manual testing before closing. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: SQL Injection indication CVSS: 8.8 Area: backend Affected asset: app.example-company.com Responsible person: Backend developer Estimated manual remediation effort: 2–4 hours AI suitability: Medium Summary: An automated scan returned a response pattern consistent with possible SQL injection on a search or query parameter. This finding is unverified and requires manual confirmation. Current recommended solution: Manually review the affected endpoint, confirm whether user input reaches a database query, and apply parameterized queries or a safe ORM API. Recommended fix steps: 1. Manually confirm the finding before making any changes — do not assume exploitation succeeded. 2. Trace the affected parameter through the codebase to where it reaches the database layer. 3. Replace string-concatenated queries with parameterized queries or a safe ORM API. 4. Add input validation as a defense-in-depth measure. 5. Re-test with the original scanner and manual testing before closing. References: - https://owasp.org/www-community/attacks/SQL_Injection Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://owasp.org/www-community/attacks/SQL_Injection --- ## 2. Exposed phpMyAdmin interface Status: Verified CVSS: 8.1 Area: sysadmin Affected asset: admin.example-company.com Responsible person: System administrator Estimated manual effort: 30–60 minutes AI suitability: Medium — AI tools can help draft the access-restriction configuration, but applying firewall/VPN changes requires manual review and testing. Summary: A phpMyAdmin database administration interface is publicly accessible without IP restriction. Current recommended solution: Restrict access to trusted IP addresses or a VPN, and enforce multi-factor authentication where possible. Recommended fix steps: 1. Confirm whether the interface needs to be public. 2. Restrict access via firewall/IP allowlist or place behind a VPN. 3. Enforce strong authentication and MFA for the admin account. 4. Re-scan to confirm the interface is no longer publicly reachable. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: Exposed phpMyAdmin interface CVSS: 8.1 Area: sysadmin Affected asset: admin.example-company.com Responsible person: System administrator Estimated manual remediation effort: 30–60 minutes AI suitability: Medium Summary: A phpMyAdmin database administration interface is publicly accessible without IP restriction. Current recommended solution: Restrict access to trusted IP addresses or a VPN, and enforce multi-factor authentication where possible. Recommended fix steps: 1. Confirm whether the interface needs to be public. 2. Restrict access via firewall/IP allowlist or place behind a VPN. 3. Enforce strong authentication and MFA for the admin account. 4. Re-scan to confirm the interface is no longer publicly reachable. References: - https://owasp.org/www-community/attacks/Brute_force_attack Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://owasp.org/www-community/attacks/Brute_force_attack --- ## 3. Outdated JavaScript library (jQuery) Status: Verified CVSS: 7.5 Area: frontend Affected asset: www.example-company.com Responsible person: Frontend developer Estimated manual effort: 1–2 hours AI suitability: High — AI tools can typically help prepare the update and code changes, but the result must still be reviewed and tested. Summary: An outdated version of the jQuery library was detected, which may be affected by known cross-site scripting issues. Current recommended solution: Update jQuery to the latest stable 3.x release and re-test the affected pages. Recommended fix steps: 1. Identify all pages/templates loading the outdated library. 2. Update to the latest stable version. 3. Re-test affected pages for compatibility. 4. Re-scan to confirm the outdated version is no longer served. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: Outdated JavaScript library (jQuery) CVSS: 7.5 Area: frontend Affected asset: www.example-company.com Responsible person: Frontend developer Estimated manual remediation effort: 1–2 hours AI suitability: High Summary: An outdated version of the jQuery library was detected, which may be affected by known cross-site scripting issues. Current recommended solution: Update jQuery to the latest stable 3.x release and re-test the affected pages. Recommended fix steps: 1. Identify all pages/templates loading the outdated library. 2. Update to the latest stable version. 3. Re-test affected pages for compatibility. 4. Re-scan to confirm the outdated version is no longer served. References: - https://nvd.nist.gov/vuln/detail/CVE-2020-11023 Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://nvd.nist.gov/vuln/detail/CVE-2020-11023 --- ## 4. TLS 1.0 supported Status: Verified CVSS: 4.3 Area: sysadmin Affected asset: www.example-company.com Responsible person: System administrator Estimated manual effort: 30–60 minutes AI suitability: High — AI tools can typically help prepare a configuration or update procedure, but changes must still be reviewed and tested. Summary: The server accepts connections using the deprecated TLS 1.0 protocol (and TLS 1.1). Current recommended solution: Disable TLS 1.0 and TLS 1.1, and allow only TLS 1.2 and TLS 1.3. Recommended fix steps: 1. Review current TLS configuration on the web server / load balancer. 2. Disable TLS 1.0 and TLS 1.1. 3. Confirm TLS 1.2/1.3 cipher suites follow current Mozilla guidelines. 4. Re-test with an SSL/TLS scanner. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: TLS 1.0 supported CVSS: 4.3 Area: sysadmin Affected asset: www.example-company.com Responsible person: System administrator Estimated manual remediation effort: 30–60 minutes AI suitability: High Summary: The server accepts connections using the deprecated TLS 1.0 protocol (and TLS 1.1). Current recommended solution: Disable TLS 1.0 and TLS 1.1, and allow only TLS 1.2 and TLS 1.3. Recommended fix steps: 1. Review current TLS configuration on the web server / load balancer. 2. Disable TLS 1.0 and TLS 1.1. 3. Confirm TLS 1.2/1.3 cipher suites follow current Mozilla guidelines. 4. Re-test with an SSL/TLS scanner. References: - https://wiki.mozilla.org/Security/Server_Side_TLS Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://wiki.mozilla.org/Security/Server_Side_TLS --- ## 5. Backup file publicly accessible Status: Verified CVSS: 7.5 Area: backend Affected asset: www.example-company.com/backup.zip Responsible person: Backend developer / DevOps Estimated manual effort: 15–30 minutes AI suitability: Low — requires manual review of file contents and judgement about credential rotation; not suitable for automatic AI action. Summary: A backup archive was found at a publicly reachable path on the website. Current recommended solution: Remove the backup file from the public web root and store backups outside of publicly served directories. Recommended fix steps: 1. Confirm what the backup file contains. 2. Remove it from the public web root immediately. 3. Move backups to a non-public storage location with restricted access. 4. Review server/CI configuration to prevent backups being written into public folders in the future. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: Backup file publicly accessible CVSS: 7.5 Area: backend Affected asset: www.example-company.com/backup.zip Responsible person: Backend developer / DevOps Estimated manual remediation effort: 15–30 minutes AI suitability: Low Summary: A backup archive was found at a publicly reachable path on the website. Current recommended solution: Remove the backup file from the public web root and store backups outside of publicly served directories. Recommended fix steps: 1. Confirm what the backup file contains. 2. Remove it from the public web root immediately. 3. Move backups to a non-public storage location with restricted access. 4. Review server/CI configuration to prevent backups being written into public folders in the future. References: - https://owasp.org/www-project-web-security-testing-guide/ Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://owasp.org/www-project-web-security-testing-guide/ --- ## 6. Missing DMARC policy Status: Unverified CVSS: 0.0 Area: sysadmin (DNS) Affected asset: example-company.com (DNS) Responsible person: System administrator Estimated manual effort: 30–60 minutes AI suitability: Medium — AI tools can help draft the DNS record and rollout plan, but publishing DNS changes must be done and verified manually. Summary: No DMARC (`_dmarc` TXT) record was found for the domain. Without DMARC, it is harder to detect and restrict email spoofing of this domain. This finding is unverified — confirm current DNS records before making changes. Current recommended solution: Publish a DMARC policy starting in monitoring mode, after confirming SPF and DKIM are correctly configured for all legitimate senders. Recommended fix steps: 1. Confirm whether SPF and DKIM are already configured correctly for the domain. 2. Identify all systems that legitimately send email on behalf of the domain. 3. Publish a DMARC TXT record with a monitoring-only policy (p=none) and an aggregate report address. 4. Monitor DMARC aggregate reports for a period of time. 5. Gradually move to a stricter policy (quarantine, then reject) once reports confirm no legitimate mail is affected. ### AI remediation prompt ``` You are helping remediate a security finding in a production environment. Important rules: - Do not apply changes automatically. - Do not provide offensive exploitation steps. - Prepare implementation guidance only. - Flag assumptions and risks. - Recommend testing before deploying to production. - If information is missing, state what needs to be verified. Finding: Name: Missing DMARC policy CVSS: 0.0 Area: sysadmin (DNS) Affected asset: example-company.com (DNS) Responsible person: System administrator Estimated manual remediation effort: 30–60 minutes AI suitability: Medium Summary: No DMARC (_dmarc TXT) record was found for the domain. Without DMARC, it is harder to detect and restrict email spoofing of this domain. This finding is unverified — confirm current DNS records before making changes. Current recommended solution: Publish a DMARC policy starting in monitoring mode, after confirming SPF and DKIM are correctly configured for all legitimate senders. Recommended fix steps: 1. Confirm whether SPF and DKIM are already configured correctly for the domain. 2. Identify all systems that legitimately send email on behalf of the domain. 3. Publish a DMARC TXT record with a monitoring-only policy (p=none) and an aggregate report address. 4. Monitor DMARC aggregate reports for a period of time. 5. Gradually move to a stricter policy (quarantine, then reject) once reports confirm no legitimate mail is affected. References: - https://dmarc.org/overview/ Prepare: 1. A short explanation of the risk. 2. A safe remediation plan. 3. A step-by-step implementation checklist. 4. Rollback recommendations. 5. Verification steps after the change. 6. Assumptions or missing information that need to be verified before changing anything. ``` References: - https://dmarc.org/overview/