Vulnerability-Lookup

GCVE-1988-2026-0445

Vulnerability from gna-1988 – Published: 2026-11-02 07:29 – Updated: 2026-11-02 07:29

Title

[Bugtraq] CVE-2026-72705: Rocq guard checker accepts fixpoint passed as higher-order argument (0 = 1 demonstrated)

Summary

1. Summary ========== A soundness bug in the Rocq (formerly Coq) kernel's guard checker allows construction of a checked proof of False — and by extension, any proposition, including 0 = 1 — without axioms, tactics, plugins, or unsafe flags. Print Assumptions reports the proof as closed under the global context. The guard checker does not track recursive calls made through a fixpoint's own arguments. A fixpoint can pass itself to another fixpoint, which can apply it to a value that is not a structural subterm. Passing the function to a plain definition is correctly rejected, but passing it to a fixpoint is accepted. This admits a type that is definitionally equal to its own negation, and self-application yields False in purely definitional code. 2. Context ========== Rocq (formerly Coq) is the reference implementation of the Calculus of Inductive Constructions and one of the most widely deployed proof assistants. Its kernel is the trusted core that checks every proof before acceptance. A soundness bug in the guard checker — the component that enforces termination of recursive definitions — undermines the guarantees of any system built on Rocq-checked proofs. Formally verified systems certified under Common Criteria (ISO 15408) or DO-178C (airborne software) derive their assurance from the correctness of the proof checker. A kernel-level bypass invalidates that assurance chain. This bug was discovered by Claude Opus 4.6 (Anthropic) during a fuzzing campaign. 3. Impact ========= - Formally verified compilers (CompCert) - Verified OS kernels (CertiKOS) - Separation logic frameworks (Iris) - Mathematical libraries (MathComp) - Proof-carrying code: a malicious .v file in a dependency could introduce unsound declarations - Verified smart contracts (ConCert) 4. Proof of Concept =================== A Docker-reproducible PoC is available: git clone https://github.com/endrazine/rocq-cve-poc-21683 cd rocq-cve-poc-21683 docker build -t rocq-cve-poc-21683 . docker run --rm rocq-cve-poc-21683 On a vulnerable version (Rocq <9.2.0, all Coq versions), the output confirms the proof of False with no axioms. On a patched version (≥9.2.0), the guard checker rejects the fixpoint. 5. Root Cause ============= The guard checker does not follow the flow of a fixpoint value when it is passed as an argument to another fixpoint. The receiving fixpoint can apply the passed function to an arbitrary value, bypassing the structural decrease requirement. This creates a type T that is definitionally equal to T -> False (its own negation). Self-application of a term of type T yields False, entirely through definitional reduction — no tactics are involved. CWE-670: Always-Incorrect Control Flow Implementation. 6. Scoring ========== CVSS 3.1: AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N — 7.1 (High) CVSS 4.0: AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N — 6.8 (Medium) 7. CWE ====== CWE-670: Always-Incorrect Control Flow Implementation 8. CVE ====== CVE-2026-72705 (assigned by VulnCheck as CNA) 9. Affected Versions ==================== Rocq Prover <9.2.0 (all versions including Coq 8.x with the guard checker) Fixed in: 9.2.0 10. Mitigation ============== - Upgrade to Rocq 9.2.0 or later. - Run coqchk on compiled .vo files as defense-in-depth. 11. References ============== Bug report: https://github.com/rocq-prover/rocq/issues/21683 Fix: https://github.com/rocq-prover/rocq/pull/21684 PoC: https://github.com/endrazine/rocq-cve-poc-21683 VulnCheck: https://www.vulncheck.com/advisories/rocq-prover-before-guard-checker-accept... NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-72705 12. Timeline ============ 2025 Bug found by Claude Opus 4.6 during fuzzing campaign 2025 Bug reported (rocq-prover/rocq#21683) 2025 Fix merged (PR #21684) in Rocq 9.2.0 2026-08-24 CVE-2026-72705 published by VulnCheck 2026-08-24 Docker-reproducible PoC published 13. Credit ========== Bug discovery: Claude Opus 4.6 (Anthropic), Tristan Stérin (fuzzing campaign, based on pointers from Yannick Forster) Kernel fix: PR #21684 PoC packaging: Jonathan Brossard (@endrazine) — MOABI / PSIRT.com

Severity

No CVSS data available.

CWE

CWE-670

Assigner

VULNARCHIVE GNA GNA-1988

GNA scorecard E 38/100 over 556 records in the last 180 days details

References

7 references

URL	Tags
https://vuln.freearchive.org/archive/item/3980e07…	technical-descriptionexploit
https://lists.securityfocus.com/hyperkitty/list/b…	technical-description
https://github.com/endrazine/rocq-cve-poc-21683
https://github.com/rocq-prover/rocq/issues/21683
https://github.com/rocq-prover/rocq/pull/21684
https://nvd.nist.gov/vuln/detail/CVE-2026-72705
https://www.vulncheck.com/advisories/rocq-prover-…

Impacted products

1 product

Vendor	Product	Version	CPE status
rocq-prover	rocq	Affected: unknown	guessed

Credits

Jonathan Brossard

Relationships

analysis GCVE-1988-2026-0445 (this record)

related CVE-2026-72705

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "rocq",
          "vendor": "rocq-prover",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Jonathan Brossard"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "1. Summary\n==========\nA soundness bug in the Rocq (formerly Coq) kernel\u0027s guard checker allows\nconstruction of a checked proof of False \u2014 and by extension, any\nproposition, including 0 = 1 \u2014 without axioms, tactics, plugins, or\nunsafe flags. Print Assumptions reports the proof as closed under the\nglobal context.\nThe guard checker does not track recursive calls made through a\nfixpoint\u0027s own arguments. A fixpoint can pass itself to another\nfixpoint, which can apply it to a value that is not a structural\nsubterm. Passing the function to a plain definition is correctly\nrejected, but passing it to a fixpoint is accepted. This admits a type\nthat is definitionally equal to its own negation, and self-application\nyields False in purely definitional code.\n2. Context\n==========\nRocq (formerly Coq) is the reference implementation of the Calculus of\nInductive Constructions and one of the most widely deployed proof\nassistants. Its kernel is the trusted core that checks every proof\nbefore acceptance. A soundness bug in the guard checker \u2014 the component\nthat enforces termination of recursive definitions \u2014 undermines the\nguarantees of any system built on Rocq-checked proofs.\nFormally verified systems certified under Common Criteria (ISO 15408) or\nDO-178C (airborne software) derive their assurance from the correctness\nof the proof checker. A kernel-level bypass invalidates that assurance\nchain.\nThis bug was discovered by Claude Opus 4.6 (Anthropic) during a\nfuzzing campaign.\n3. Impact\n=========\n- Formally verified compilers (CompCert)\n- Verified OS kernels (CertiKOS)\n- Separation logic frameworks (Iris)\n- Mathematical libraries (MathComp)\n- Proof-carrying code: a malicious .v file in a dependency could\nintroduce unsound declarations\n- Verified smart contracts (ConCert)\n4. Proof of Concept\n===================\nA Docker-reproducible PoC is available:\ngit clone https://github.com/endrazine/rocq-cve-poc-21683\ncd rocq-cve-poc-21683\ndocker build -t rocq-cve-poc-21683 .\ndocker run --rm rocq-cve-poc-21683\nOn a vulnerable version (Rocq \u003c9.2.0, all Coq versions), the output\nconfirms the proof of False with no axioms. On a patched version\n(\u22659.2.0), the guard checker rejects the fixpoint.\n5. Root Cause\n=============\nThe guard checker does not follow the flow of a fixpoint value when it\nis passed as an argument to another fixpoint. The receiving fixpoint can\napply the passed function to an arbitrary value, bypassing the\nstructural decrease requirement.\nThis creates a type T that is definitionally equal to T -\u003e False (its\nown negation). Self-application of a term of type T yields False,\nentirely through definitional reduction \u2014 no tactics are involved.\nCWE-670: Always-Incorrect Control Flow Implementation.\n6. Scoring\n==========\nCVSS 3.1: AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N \u2014 7.1 (High)\nCVSS 4.0: AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N \u2014 6.8\n(Medium)\n7. CWE\n======\nCWE-670: Always-Incorrect Control Flow Implementation\n8. CVE\n======\nCVE-2026-72705 (assigned by VulnCheck as CNA)\n9. Affected Versions\n====================\nRocq Prover \u003c9.2.0 (all versions including Coq 8.x with the guard\nchecker)\nFixed in: 9.2.0\n10. Mitigation\n==============\n- Upgrade to Rocq 9.2.0 or later.\n- Run coqchk on compiled .vo files as defense-in-depth.\n11. References\n==============\nBug report:  https://github.com/rocq-prover/rocq/issues/21683\nFix:         https://github.com/rocq-prover/rocq/pull/21684\nPoC:         https://github.com/endrazine/rocq-cve-poc-21683\nVulnCheck:\nhttps://www.vulncheck.com/advisories/rocq-prover-before-guard-checker-accept...\nNVD:         https://nvd.nist.gov/vuln/detail/CVE-2026-72705\n12. Timeline\n============\n2025        Bug found by Claude Opus 4.6 during fuzzing campaign\n2025        Bug reported (rocq-prover/rocq#21683)\n2025        Fix merged (PR #21684) in Rocq 9.2.0\n2026-08-24  CVE-2026-72705 published by VulnCheck\n2026-08-24  Docker-reproducible PoC published\n13. Credit\n==========\nBug discovery:   Claude Opus 4.6 (Anthropic), Tristan St\u00e9rin\n(fuzzing campaign, based on pointers from Yannick Forster)\nKernel fix:      PR #21684\nPoC packaging:   Jonathan Brossard (@endrazine) \u2014 MOABI / PSIRT.com"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-670",
              "description": "CWE-670",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:29:46Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/item/3980e073a4d3a439116db68b9bd034c52bdfd611a3e14ae68dd1c41364a8bb31"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://lists.securityfocus.com/hyperkitty/list/bugtraq@bugtraq.ai/message/Y4CBS4TQ2JSVXQB5A4Q5LQ44QV47Z76S/"
        },
        {
          "url": "https://github.com/endrazine/rocq-cve-poc-21683"
        },
        {
          "url": "https://github.com/rocq-prover/rocq/issues/21683"
        },
        {
          "url": "https://github.com/rocq-prover/rocq/pull/21684"
        },
        {
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72705"
        },
        {
          "url": "https://www.vulncheck.com/advisories/rocq-prover-before-guard-checker-accepts-fixpoint-passed-as-a-higher-order-argument"
        }
      ],
      "source": {
        "defect": [
          "997fa663-d85e-4888-8aff-6a8c17040bf2%40gmail.com"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[Bugtraq] CVE-2026-72705: Rocq guard checker accepts fixpoint passed as higher-order argument (0 = 1 demonstrated)",
      "x_gcve": [
        {
          "recordType": "analysis",
          "relationships": [
            {
              "destId": "CVE-2026-72705",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0445",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/item/3980e073a4d3a439116db68b9bd034c52bdfd611a3e14ae68dd1c41364a8bb31",
            "automated": true,
            "contentSha256": "3980e073a4d3a439116db68b9bd034c52bdfd611a3e14ae68dd1c41364a8bb31",
            "evidenceScore": 10,
            "messageId": "997fa663-d85e-4888-8aff-6a8c17040bf2%40gmail.com",
            "originalUrl": "https://lists.securityfocus.com/hyperkitty/list/bugtraq@bugtraq.ai/message/Y4CBS4TQ2JSVXQB5A4Q5LQ44QV47Z76S/",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-11-02T07:29:46Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0445"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:29:46Z",
    "dateUpdated": "2026-11-02T07:29:46Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0445"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-72705 (GCVE-0-2026-72705)

Vulnerability from cvelistv5 – Published: 2026-08-24 20:08 – Updated: 2026-10-26 01:23

Title

Rocq Prover before 9.2.0 Guard Checker Accepts Fixpoint Passed as a Higher-Order Argument

Summary

The guard checker in Rocq Prover does not follow recursive calls made through a fixpoint's own arguments. A fixpoint may pass itself as a higher-order argument to a second fixpoint, which then applies it to a value that is not a subterm of the structural argument. Passing the recursive function to a plain definition is rejected because the checker unfolds the definition and observes the call, but passing it to a fixpoint is accepted because higher-order recursive calls through fixpoint arguments are not tracked. This admits a type that is definitionally equal to its own negation, so self-application produces False in purely definitional code, without tactics, axioms, plugins or unsafe flags, and Print Assumptions reports the result as closed under the global context. Fixed in Rocq 9.2.0.

Severity

6.8 (Medium)


                        
                          CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

6.3 (Medium)


                        
                          CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-26 15:46 UTC

CWE

CWE-670 - Always-Incorrect Control Flow Implementation

Assigner

VulnCheck CNA under the mitre root

CNA scorecard B 84/100 over 7611 records in the last 180 days details

References

6 references

URL	Tags
https://github.com/rocq-prover/rocq	product
https://github.com/rocq-prover/rocq/issues/21683	issue-tracking
https://github.com/rocq-prover/rocq/pull/21684	issue-trackingpatch
https://github.com/endrazine/rocq-cve-poc-21683	exploit
https://www.vulncheck.com/advisories/rocq-prover-…	third-party-advisory
http://www.openwall.com/lists/oss-security/2026/10/26/6

Impacted products

1 product

Vendor	Product	Version
rocq-prover	rocq	Affected: 0 , < 9.2.0 (custom)

Date Public

2026-02-28 00:00

Credits

Tristan Stérin Jonathan Brossard (MOABI)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-72705",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-26T15:46:51.503814Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-26T16:13:14.137Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-26T01:23:56.439Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/26/6"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:github/rocq-prover/rocq",
          "product": "rocq",
          "repo": "https://github.com/rocq-prover/rocq",
          "vendor": "rocq-prover",
          "versions": [
            {
              "lessThan": "9.2.0",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Tristan St\u00e9rin"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Jonathan Brossard (MOABI)"
        }
      ],
      "datePublic": "2026-02-28T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "The guard checker in Rocq Prover does not follow recursive calls made through a fixpoint\u0027s own arguments. A fixpoint may pass itself as a higher-order argument to a second fixpoint, which then applies it to a value that is not a subterm of the structural argument. Passing the recursive function to a plain definition is rejected because the checker unfolds the definition and observes the call, but passing it to a fixpoint is accepted because higher-order recursive calls through fixpoint arguments are not tracked. This admits a type that is definitionally equal to its own negation, so self-application produces False in purely definitional code, without tactics, axioms, plugins or unsafe flags, and Print Assumptions reports the result as closed under the global context. Fixed in Rocq 9.2.0."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "PASSIVE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-670",
              "description": "Always-Incorrect Control Flow Implementation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-24T14:18:52.758Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "tags": [
            "product"
          ],
          "url": "https://github.com/rocq-prover/rocq"
        },
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/rocq-prover/rocq/issues/21683"
        },
        {
          "tags": [
            "issue-tracking",
            "patch"
          ],
          "url": "https://github.com/rocq-prover/rocq/pull/21684"
        },
        {
          "tags": [
            "exploit"
          ],
          "url": "https://github.com/endrazine/rocq-cve-poc-21683"
        },
        {
          "name": "VulnCheck Advisory: Rocq Prover before 9.2.0 Guard Checker Accepts Fixpoint Passed as a Higher-Order Argument",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/rocq-prover-before-guard-checker-accepts-fixpoint-passed-as-a-higher-order-argument"
        }
      ],
      "title": "Rocq Prover before 9.2.0 Guard Checker Accepts Fixpoint Passed as a Higher-Order Argument",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-72705",
    "datePublished": "2026-08-24T20:08:32.535Z",
    "dateReserved": "2026-08-10T13:02:52.001Z",
    "dateUpdated": "2026-10-26T01:23:56.439Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted