# Detection Rules (SIEM) exceptions bug?

**URL:** <https://discuss.elastic.co/t/detection-rules-siem-exceptions-bug/378531>\
**Category:** Elastic Security\
**Tags:** detection-rules\
**Created:** [May 26, 2025, 8:01am UTC](https://discuss.elastic.co/t/detection-rules-siem-exceptions-bug/378531 "2025-05-26T08:01:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![marrc.rousseau](https://avatars.discourse-cdn.com/v4/letter/m/2acd7d/32.png) [@marrc.rousseau](https://discuss.elastic.co/u/marrc.rousseau)\
**Post date:** [May 26, 2025, 8:01am UTC](https://discuss.elastic.co/t/detection-rules-siem-exceptions-bug/378531/1 "2025-05-26T08:01:06Z")

</div>

Hello,

Everytime I try to create an exception for builtin security rule "Enumeration of Kernel Modules" I receive an error :

```auto
type: Invalid literal value, expected "new_terms", language: Invalid enum value. Expected 'kuery' | 'lucene', received 'eql' (400)
{
  "name": "Error",
  "body": {
    "message": "type: Invalid literal value, expected \"new_terms\", language: Invalid enum value. Expected 'kuery' | 'lucene', received 'eql'",
    "status_code": 400
  },
  "message": "Bad Request",
  "stack": "Error: Bad Request\n at fetch_Fetch.fetchResponse (https://xxx/d7985c806432/bundles/core/core.entry.js:16:232024)\n at async https://xxx/d7985c806432/bundles/core/core.entry.js:16:230016\n at async https://xxx/d7985c806432/bundles/core/core.entry.js:16:229973"
}

```

Here are some screenshots:

 ![2025-05-26_09h52_13](https://us1.discourse-cdn.com/elastic/original/3X/a/d/adeec57c577f8d16e16d0ea80ac3ccbd74520654.png)  
 ![2025-05-26_09h52_24](https://us1.discourse-cdn.com/elastic/original/3X/b/0/b09979ab41bcd924a25c823528888f013f03f886.png)

I also tried with API

```auto
POST kbn:/api/detection_engine/rules/30ef3bf0-fb00-11ed-b238-dffaf1b25f7d/exceptions
{
  "items": [
    {
      "comments": [],
      "description": "Exception list item",
      "entries": [
        {
          "field": "user.name",
          "operator": "included",
          "type": "match",
          "value": "root"
        }
      ],
      "name": "test",
      "namespace_type": "single",
      "tags": [],
      "type": "simple"
    }
  ]
}

```

I've got the same error ☹

Elastic version : 8.17.2

Any idea ?

Thanks

---

<div class="post-metadata">

**Author:** ![yctercero](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yctercero/32/68560_2.png) [@yctercero](https://discuss.elastic.co/u/yctercero)\
**Post date:** [May 27, 2025, 5:25pm UTC](https://discuss.elastic.co/t/detection-rules-siem-exceptions-bug/378531/2 "2025-05-27T17:25:25Z")

</div>

Hi @marrc.rousseau !

I checked out 8.17.2 and was able to successfully add an exception to "Enumeration of Kernel Modules".

I don't see anything jump out on the exception side. The error message makes me think there's something odd happening on the rule side.

Would you be able to share a HAR? I'd be curious to see what rule version you're using and see if I can recreate using that specific version.

---

<div class="post-metadata">

**Author:** ![marrc.rousseau](https://avatars.discourse-cdn.com/v4/letter/m/2acd7d/32.png) [@marrc.rousseau](https://discuss.elastic.co/u/marrc.rousseau)\
**Post date:** [May 28, 2025, 6:18am UTC](https://discuss.elastic.co/t/detection-rules-siem-exceptions-bug/378531/3 "2025-05-28T06:18:22Z")

</div>

Hi @yctercero

Thanks for your reply

For an unknow reason there are two rules "Enumeration of Kernel Modules"

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/b/8/b8adc1c07f3d6937014e1a910d3b84757fe3840d.png)

First one is

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/f/f/ff69c5320785be774b6add8148dabad4334860c9.png)

Second one is

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/c/8/c846ce7c58d528a9896d77ec9650d8c56e2d7229.png)

Looks like the first one is an old one  
Creating an exception on both rules triggers the error

I deleted the old one, enabled the second one, create an exception and now no more error.

Apparently the problem came from a conflict between these two versions of the same rule

Problem solved.

Thanks