By submitting a report or conducting security research under this program, you agree to:

• Respect the Community Code of Conduct
• Respect the Intigriti Terms and Conditions
• Respect the scope of the program
• Not discuss or disclose vulnerability information without prior written consent (including PoC's on YouTube and Vimeo)
• Review and respect the current scope and all program-specific restrictions before conducting any security testing.
• Test only assets explicitly included within the published scope of this program.
• Conduct research in good faith and use only the minimum testing necessary to identify and demonstrate a potential vulnerability.
• Avoid any activity that could negatively affect the confidentiality, integrity, availability, safety, or normal operation of Autoliv products, systems, services, data, or business processes.
• Use researcher-owned accounts or test accounts explicitly authorized for testing. Do not access another person’s account or use stolen, leaked, purchased, shared, or otherwise unauthorized credentials.
• Avoid accessing personal data, customer information, employee information, credentials, confidential business information, or other sensitive data.
• Stop testing immediately if you encounter sensitive information, gain unintended access to another user’s account, affect a safety-related function, or observe evidence of an active compromise.
• Do not download, copy, modify, delete, retain, or publicly disclose data beyond the minimum evidence necessary to demonstrate the vulnerability.
• Submit findings promptly and exclusively through the Autoliv Vulnerability Disclosure Program on Intigriti.
• Provide clear, complete, and reproducible information, including the affected asset, reproduction steps, supporting evidence, and demonstrated security impact.
• Maintain the confidentiality of all vulnerability information.
• Not discuss or disclose vulnerability information without Autoliv’s prior written consent. This includes proof-of-concept material, screenshots, videos, source code, technical write-ups, conference presentations, blog posts, social-media content, and submissions to public vulnerability databases.
• Allow Autoliv reasonable time to investigate, remediate, and, where necessary, coordinate with customers, suppliers, or other affected parties.
• Comply promptly with requests from Intigriti or Autoliv to stop, limit, or modify testing activity.
• Securely delete any vulnerability-related evidence containing Autoliv information when it is no longer needed for coordinated vulnerability handling.
• Comply with applicable laws and regulations.

The presence of an asset under *.autoliv.com or *.autoliv.biz does not necessarily mean that the asset is operated or directly controlled by Autoliv. If ownership is unclear, or if an asset appears to be operated by a customer, supplier, partner, or other third party, researchers must stop testing and submit the available information through Intigriti. Autoliv and Intigriti will determine whether the asset is eligible under this program.

Minimal and non-destructive proof of concept

Researchers must use the least intrusive method necessary to demonstrate a potential vulnerability. A report does not need to demonstrate the full extent of possible exploitation.

In particular, researchers must not:

• Access multiple user or customer records when one minimal example is sufficient.
• Extract complete datasets.
• Establish persistence.
• Move laterally to another system.
• Escalate privileges beyond what is necessary to demonstrate the issue.
• Execute destructive commands or payloads.
• Complete fraudulent or unauthorized transactions.
• Create financial, contractual, operational, or customer impact.

Where possible, researchers should use synthetic information and researcher-owned accounts. Screenshots and other supporting evidence must be sanitized to remove unrelated personal, confidential, or sensitive information.

When to stop testing

Researchers must immediately stop testing and submit a report through Intigriti if they:

• Access personal, customer, employee, supplier, or confidential business information.
• Obtain access to credentials, authentication tokens, private keys, or secrets.
• Gain access to an account that does not belong to them.
• Identify a condition that could disrupt a production service.
• Encounter an operational-technology, manufacturing, vehicle, embedded, or safety-related system.
• Observe evidence of active exploitation or compromise.
• Discover that an asset may belong to or be operated by a third party.
• Receive a request from Intigriti or Autoliv to stop testing.

Continued testing after one of these conditions has been identified may fall outside the authorization provided by this program.

Testing volume and coordination

Testing must be low-volume, targeted, non-destructive, and proportionate to the vulnerability being investigated.

Researchers must not conduct volumetric, stress, load, brute-force, resource-exhaustion, or production-capacity testing.

Where a proposed test may generate material traffic, create records, affect production behavior, or require activity beyond a minimal proof of concept, the researcher must first submit the proposed test through Intigriti and obtain explicit written authorization from Autoliv.

Absence of a response does not constitute authorization.

Reporting requirements

Researchers must:

Submit one report per distinct vulnerability unless multiple issues must be combined to demonstrate a single attack chain.
Clearly identify the affected asset.
Provide complete and reproducible steps.
Include the minimum viable proof of concept.
Explain the demonstrated security and business impact.
Identify any test accounts, tagged dummy data, generated records, or unusual requests created during testing.
Redact unrelated personal, confidential, or sensitive information.
Avoid including secrets in plain text where a partially redacted value is sufficient for validation.

Coordinated disclosure

Researchers must not publicly disclose vulnerability information unless and until Autoliv provides explicit written authorization.

This restriction includes proof-of-concept material, screenshots, videos, exploit code, technical write-ups, conference presentations, blog posts, social-media posts, and submissions to public vulnerability databases.

Submission of a report does not itself constitute authorization for public disclosure.

Hard-stop restrictions

A valid vulnerability does not authorize further exploitation. Researchers must stop after obtaining the minimum evidence necessary to establish the existence and security impact of the issue.

The following activities are prohibited.

No data exfiltration

Researchers must not extract databases, tables, user lists, software catalogues, document collections, or other datasets.

Where read access is unintentionally obtained, the proof of concept must be limited to the minimum evidence necessary, such as:

• A row count.
• A table or column name.
• A single redacted record.
• Metadata demonstrating that unauthorized access exists.

Researchers must not access additional records once the issue has been demonstrated.

No credential or token reuse

A credential, managed identity, connection string, private key, SAS token, Entra token, session token, API key, or other secret discovered through testing must be reported and must not be used beyond the minimum action necessary to establish that it is exposed.

Researchers must not use discovered credentials or tokens to access:

• Azure management or control-plane services.
• Microsoft Graph.
• Microsoft Entra ID.
• Azure SQL or Microsoft SQL Server.
• Any third-party service, platform, tenant, subscription, application, or environment.
• Any other user, system, service, tenant, subscription, or environment.

A discovered token is evidence to be reported, not authorization to use it.

Successful access obtained through the use of an exposed credential or token may be considered out of scope if the vulnerability report depends primarily on the use of that credential rather than the underlying exposure.

No persistence

Researchers must not establish or attempt to establish persistence, including through:

• Web shells or remote-access tools.
• Scheduled tasks or automated jobs.
• New users or service accounts.
• New application registrations.
• New role assignments or permission grants.
• New Sanity documents or records.
• Modified startup, deployment, or authentication configuration.
• Any persistent payload or access mechanism.

No unauthorized writes or deletions

Researchers must not create, modify, or delete:

• Database records.
• Content-management-system content.
• Production application data.
• ServiceNow tickets or ticket-queue records.
• User profiles or role assignments.
• Application configuration.
• Cloud resources.
• Files, software artefacts, or documents.

If testing submitContactForm or submitSupportForm is expressly authorized, researchers must use clearly identifiable dummy information containing:

intigriti-<researcher-id>

The resulting submission must be identified in the report so that Autoliv can locate and remove it.

No lateral movement

Researchers must not move from an in-scope application to another user, system, service, tenant, network, subscription, or environment.

Session-management and JSON Web Token vulnerabilities must be demonstrated exclusively through researcher-controlled accounts. Researchers must not access another person’s session, account, profile, files, or downloads.

No destructive or availability testing

Researchers must not perform:

• Denial-of-service or distributed-denial-of-service testing.
• Volumetric scanning.
• Stress or load testing.
• Rate-limit exhaustion.
• Resource-consumption fuzzing.
• Destructive payload execution.
• Testing likely to degrade the performance, availability, reliability, or safety of a production service.

Automated testing must be low-volume, targeted, and non-disruptive. Researchers must stop if their activity causes or appears likely to cause instability.

No modification of the running application

Researchers must not make deployment changes or modify application code, configuration, environment variables, infrastructure, feature flags, access assignments, or runtime settings.

For /api/draft-mode/enable, proof must stop after:

1. Obtaining the draft-mode cookie; and
2. Demonstrating access to draft content using the minimum necessary evidence.

Researchers must not publish, alter, delete, or intentionally expose draft content through the live application.

No downloading of protected software artefacts

Researchers must not download software artefacts, packages, binaries, documents, or other controlled intellectual property available through the UserPortal.

Where an authorization bypass affects download functionality, the researcher must use the minimum request or response evidence necessary to demonstrate the issue. The underlying artefact must not be downloaded, retained, copied, executed, or distributed.

Accidental access to sensitive information

If a researcher unintentionally accesses personal data, employee information, customer information, supplier information, credentials, authentication tokens, private keys, confidential business information, controlled intellectual property, or any other sensitive information, the researcher must:

1. Stop testing immediately.
2. Not access any additional records or information.
3. Not download, copy, save, modify, delete, transmit, or disclose the information.
4. Capture only the minimum redacted evidence necessary to establish the vulnerability.
5. Report the issue through Intigriti within 24 hours of discovery.
6. Protect any temporarily retained evidence against unauthorized access.
7. Securely delete local copies after Autoliv or Intigriti confirms receipt, unless preservation is required by applicable law.

Continued access after sensitive information has been encountered may fall outside the authorization provided by this program.

Introduction

We are happy to announce our program! We've done our best to clean up our known issues and now would like to request your help to spot the ones we missed!

Autoliv welcomes the responsible disclosure of potential security vulnerabilities affecting the publicly accessible Autoliv assets identified in this section.

This Vulnerability Disclosure Program provides a structured channel through which security researchers may report vulnerabilities they encounter or identify through good-faith, non-disruptive security research.

This is a Vulnerability Disclosure Program and not a Bug Bounty Program. Autoliv does not offer or guarantee monetary rewards for reports submitted through this program.

Authorized scope

Only assets explicitly listed in the Assets section of this program are authorized for security testing.

The presence of an Autoliv name, logo, certificate, DNS record, IP address, or domain suffix does not by itself place an asset within scope.

The wildcard entries *.autoliv.com and *.autoliv.biz, where listed as in-scope assets, apply only to publicly accessible web applications, services, and APIs that:

• Are operated or directly controlled by Autoliv.
• Are not separately identified as out of scope.
• Are not customer, supplier, partner, employee, internal, development, staging, test, manufacturing, operational-technology, vehicle, embedded, or safety-related systems.
• Can be tested without accessing internal networks, restricted environments, or third-party services.
• Can be tested without negatively affecting safety, manufacturing, business operations, customers, employees, suppliers, or other third parties.
• Do not display instructions prohibiting testing or directing researchers to another vulnerability-disclosure process.

Where an individual asset or system has asset-specific restrictions, those restrictions take precedence over the general wildcard scope.

If the ownership, purpose, or eligibility of an asset is unclear, researchers must stop testing and submit the available information through Intigriti. Autoliv and Intigriti will determine whether the asset is eligible under this program.

Internal inventories, tickets, engagement records, or identifiers that are not published in this program do not constitute authorization to test an asset.

Scope under development

The scope of the Autoliv VDP is currently being reviewed and may be refined as asset ownership, technical dependencies, operational risks, and remediation responsibilities are confirmed.

Additional assets and asset categories may be added following consultation with the relevant Autoliv product, cloud infrastructure, API connectivity, security, legal, privacy, and business owners.

Researchers must review the program scope and rules before conducting any testing, as the scope and asset-specific restrictions may change over time.

Only assets explicitly covered by the current published program policy are authorized for testing. Future scope categories, stakeholder discussions, or planned additions do not constitute authorization to test an asset.

Areas of interest

Autoliv is particularly interested in reproducible vulnerabilities that demonstrate a meaningful impact on the confidentiality, integrity, or availability of an eligible in-scope asset.

The examples below are intended as guidance. They do not override the published scope, rules of engagement, or out-of-scope restrictions.

Access control and authorization

Examples include:

• Vertical or horizontal privilege escalation.
• Unauthorized access to another user’s data or functionality.
• Insecure direct object reference, or IDOR, with demonstrated unauthorized access.
• Broken object-level authorization.
• Broken function-level authorization.
• Authorization bypass affecting sensitive operations.
• Business-logic flaws permitting unauthorized transactions, requests, or actions.

Testing must be performed using researcher-owned accounts or test accounts explicitly authorized for use. Researchers must not access another person’s real account or intentionally retrieve information belonging to another user.

Authentication and session management

Examples include:

• Authentication bypass.
• Account takeover.
• Session fixation.
• Session-management weaknesses with demonstrated impact.
• JSON Web Token forgery, algorithm confusion, signature-validation failure, or acceptance of manipulated tokens.
• Password-reset vulnerabilities leading to unauthorized account access.
• Multi-factor authentication bypass.
• Exposure or reuse of valid authentication tokens.

The use of stolen, leaked, purchased, or otherwise unauthorized credentials is not permitted.

API security

Examples include:

• Broken object-level authorization.
• Broken function-level authorization.
• Excessive exposure of sensitive information.
• Mass assignment with demonstrated security impact.
• Improper authentication or authorization.
• Security misconfiguration affecting an eligible API.
• Injection vulnerabilities within API parameters.
• Researchers must not use high-volume requests to demonstrate rate-limiting issues.

Researchers must not use high-volume requests to demonstrate rate-limiting issues. A minimal, non-disruptive proof of concept is sufficient.

Cross-site and browser-based vulnerabilities

Examples include:

• Cross-site request forgery affecting sensitive or state-changing operations.
• Stored or reflected cross-site scripting with demonstrated security impact.
• Cross-origin resource-sharing misconfiguration with demonstrated unauthorized access.
• Browser-based vulnerabilities leading to account compromise, sensitive data exposure, or unauthorized actions.

Low-impact browser-security observations without a realistic exploitation scenario may not be eligible.

File and data handling

Examples include:

• Arbitrary file upload with demonstrated unauthorized execution or access.
• Local or remote file inclusion.
• Path traversal enabling access to sensitive files.
• Insecure deserialization leading to unauthorized code execution or data manipulation.
• Archive extraction vulnerabilities, including path traversal.
• Unauthorized access to sensitive files, configuration information, credentials, keys, tokens, or internal data.

Researchers must not upload malware, create intentionally destructive archives, deploy persistent payloads, or use proof-of-concept files that could consume excessive system resources.

Business-logic vulnerabilities

Examples include:

• Unauthorized modification of transactions or business records.
• Price or quantity manipulation with demonstrated impact.
• Bypass of inventory or transaction controls.
• Bypass of required approval or verification steps.
• Abuse of trusted application workflows.
• Race conditions affecting sensitive operations.
• Integer overflow or underflow affecting security-relevant business processes.
• Repeated-use or replay vulnerabilities affecting transactions or approvals.

Researchers must not complete fraudulent transactions, create business or financial commitments, interfere with legitimate orders, or cause financial loss. Testing must stop once the issue has been demonstrated using the minimum necessary actions.

Infrastructure and security configuration

Examples include:

• Server-side request forgery with demonstrated access to protected resources.
• Subdomain takeover where the condition can be demonstrated safely.
• Web-cache poisoning or cache deception with demonstrated security impact.
• Host-header injection with demonstrated business or security impact.
• Open redirection that enables credential theft, token leakage, or another material security consequence.
• Exposure of sensitive configuration data, credentials, cryptographic material, access tokens, or internal information.
• Cloud-service misconfiguration that allows demonstrable unauthorized access to Autoliv-controlled information or resources.

Researchers must not access internal services beyond the minimum necessary to establish the existence of a vulnerability. Researchers must not claim, register, modify, or retain third-party resources as part of a subdomain-takeover proof of concept unless explicitly authorized.

Eligibility conditions

A vulnerability will generally be eligible for review when all the following conditions are met:

• The affected asset is within the published scope.
• The asset is operated or directly controlled by Autoliv.
• The report demonstrates a reproducible security impact.
• Testing was conducted in good faith.
• Testing complied with the program rules.
• The researcher used the minimum activity necessary to demonstrate the issue.
• The report contains sufficient information for validation.
• The report is not a duplicate of a previously reported issue.
• The vulnerability was not publicly disclosed before Autoliv had a reasonable opportunity to investigate and address it.

The final eligibility and severity of a report will be determined by Intigriti and Autoliv based on scope, reproducibility, technical impact, business impact, and compliance with the program rules.

Data-access restrictions

Researchers must avoid accessing personal data, customer information, employee information, credentials, commercially sensitive information, or other confidential data.

If sensitive information is encountered, the researcher must:

1. Stop testing immediately.
2. Avoid accessing additional records.
3. Avoid downloading, copying, modifying, or deleting the information.
4. Report the issue promptly through Intigriti.
5. Describe only the minimum information needed to demonstrate the exposure.
6. Redact unrelated sensitive information from screenshots and other evidence.
7. Securely delete retained evidence when it is no longer required for coordinated handling.

A report does not require access to multiple records or the extraction of complete datasets. Evidence showing the minimum amount of information necessary to verify the vulnerability is sufficient.

Out-of-scope systems and environments

The following systems, environments, services, and targets are expressly excluded from testing, even if a credential, token, endpoint, connection string, URL, reference, or technical path to them is discovered through an in-scope asset.

Development and staging environments

• meuw-safetysuite-dv-web
• meuw-safetysuite-dv-api
• Any deployment slot or environment identified as development, staging, test, acceptance, preview, pre-production, or otherwise non-production, including *-staging deployment slots.

These environments may share identity, data, configuration, or technical dependencies with production systems and are not authorized for testing.

Third-party platforms and services

Third-party software-as-a-service platforms, cloud services, hosting providers, customer systems, supplier systems, partner systems, and external service providers are not authorized for testing.

A vulnerability affecting the integration between an in-scope Autoliv asset and a third-party service may be reported. However, researchers must not test, access, modify, disrupt, or otherwise interact directly with the third-party service, infrastructure, tenant, application, dataset, or management interface.

Testing authorization applies only to assets operated and controlled by Autoliv and explicitly included within this program's scope.

Microsoft identity and Azure management services

The following are excluded from testing:

• login.microsoftonline.com
• The Autoliv Microsoft Entra ID tenant
• Microsoft Azure Portal
• Azure Resource Manager and Azure management APIs
• Microsoft Graph APIs
• Microsoft-owned infrastructure and services

Authentication or authorization weaknesses originating within an in-scope Autoliv application may be reported. Researchers must not test the corporate tenant or use credentials, managed identities, access tokens, refresh tokens, or other secrets to access Microsoft identity, directory, management, or control-plane services.

Databases and backend infrastructure

The Azure SQL or Microsoft SQL Server instance is not authorized for direct network-level testing.

Potential SQL injection, access-control, or data-exposure vulnerabilities originating in an in-scope application may be reported. Testing must stop once the vulnerability has been demonstrated using the minimum necessary proof. Researchers must not connect directly to the database, enumerate database infrastructure, dump tables, modify data, or attempt privilege escalation within the database environment.

Corporate identities and communications

The following are excluded:

• Corporate email systems.
• Autoliv employee accounts.
• Shared mailboxes and distribution lists.
• Employee devices and communication channels.
• Phishing, social engineering, pretexting, impersonation, credential solicitation, or other interaction with Autoliv personnel.
• Authentication attempts using leaked, purchased, stolen, guessed, or otherwise unauthorized credentials.

Other Autoliv assets

Any Autoliv asset that is not explicitly authorized by the published Assets section and this program policy is out of scope.

This includes internal systems and any operational-technology, manufacturing, factory, vehicle, embedded, prototype, engineering, or safety-related environment unless that specific asset has been expressly listed as in scope.

Production vehicles, vehicle subsystems, embedded software, safety-related electronics, prototype hardware, manufacturing systems, laboratory equipment, operational-technology environments, and other product-security targets are currently outside the scope of this Vulnerability Disclosure Program unless expressly identified as in-scope assets.

Reports involving vehicle brands, models, production parts, embedded devices, or hardware components should only be submitted where those assets have been explicitly identified as in scope.

Out-of-scope finding classes

The following finding classes are generally not eligible for acceptance unless the report demonstrates a realistic, reproducible, and material security impact affecting an in-scope Autoliv asset:

• Missing HTTP security headers.
• Missing cookie attributes or flags.
• Absence of rate limiting without a demonstrated attack chain.
• Self-XSS that cannot affect another user.
• Clickjacking without demonstrated impact.
• Cross-site request forgery with no meaningful state-changing or security impact.
• Version disclosure or banner grabbing.
• Directory listings that do not expose sensitive information.
• Automated scanner output without manual validation and a reproducible proof of concept.
• Email spoofing and issues involving SPF, DKIM, or DMARC.
• Username or email enumeration without demonstrated security impact.
• Email bombing.
• Best-practice observations concerning password length, complexity, expiration, or reuse without a demonstrated exploit.
• Disclosure of public or non-sensitive API keys.
• CORS misconfiguration on non-sensitive endpoints.
• Open redirection without demonstrated security impact.
• Host-header injection without demonstrated security impact.
• Blind SSRF demonstrated only through a callback or pingback and without meaningful access or business impact.
• Subdomain-takeover indicators without a safely reproducible takeover condition.
• Software-version or outdated-component reports without a working proof of concept affecting the in-scope deployment.
• robots933456.txt or equivalent Azure health-probe artefacts.
• Vulnerabilities affecting upstream NextAuth v5 beta code where the report does not demonstrate that Autoliv’s implementation is exploitable.
• Theoretical issues with no realistic exploitation scenario.
• Findings requiring unrealistic or excessive user interaction.
• Findings requiring physical access, a compromised endpoint, man-in-the-middle access, or an already compromised user account.
• Spam, social engineering, phishing, physical intrusion, or impersonation.
• Denial-of-service, distributed-denial-of-service, brute-force, stress, load, or resource-exhaustion testing.

Application

• Wordpress usernames disclosure
• Pre-Auth Account takeover/OAuth squatting
• Presence of autocomplete attribute on web forms
• Reverse tabnabbing
• CSV Injection
• Sessions not being invalidated (logout, enabling 2FA, etc.)
• Tokens leaked to third parties
• Content injection without being able to modify the HTML
• HTTP Request smuggling without any proven impact
• Homograph attacks
• XMLRPC enabled
• Not stripping metadata of files
• Same-site scripting
• Arbitrary file upload without proof of the existence of the uploaded file
• Disclosed/misconfigured Google Maps API keys

General

• Previously reported or already known vulnerabilities may be classified as duplicates.
• Vulnerabilities that only affect software versions that are no longer supported by the software vendor are generally out of scope.
• Recently disclosed vulnerabilities affecting an in-scope asset within 14 days of a publicly available vendor patch or mitigation may be reported; however, report eligibility will be determined by Autoliv and Intigriti based on the circumstances of the finding.

Mobile

• Shared links leaked through the system clipboard
• Any URIs leaked because a malicious app has permission to view URIs opened
• The absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• Lack of obfuscation
• Path disclosure in the binary
• Lack of jailbreak & root detection
• Crashes due to malformed URL Schemes
• Lack of binary protection (anti-debugging) controls, mobile SSL pinning
• Snapshot/Pasteboard leakage
• Runtime hacking exploits (exploits only possible in a jailbroken environment)
• API key leakage used for insensitive activities/actions

This program follows Intigriti's triage standards based on the proof of concept.

.