tremor-script

Version	Released
`0.13.0-rc.33` unknown	Oct 23, 2024
`0.13.0-rc.30` unknown	Oct 22, 2024
`0.13.0-rc.18` unknown	Apr 10, 2024
`0.13.0-rc.11` unknown	Dec 21, 2022
`0.13.0-rc.10` unknown	Dec 02, 2022
`0.13.0-rc.9` unknown	Nov 11, 2022
`0.13.0-rc.8` unknown	Nov 09, 2022
`0.13.0-rc.6` unknown	Oct 20, 2022
`0.13.0-rc.5` unknown	Oct 05, 2022
`0.13.0-rc.4` unknown	Sep 29, 2022
`0.13.0-rc.3` unknown	Sep 16, 2022
`0.13.0-rc.2` unknown	Sep 02, 2022
`0.13.0-rc.1` unknown	Aug 19, 2022
`0.12.4` unknown	Jun 24, 2022
`0.12.3` unknown	Jun 17, 2022
`0.12.2` unknown	Jun 15, 2022
`0.12.1` unknown	Jun 01, 2022
`0.12.0` unknown	May 25, 2022
`0.12.0-rc.9` unknown	May 19, 2022
`0.12.0-rc.8` unknown	May 13, 2022
`0.11.10` unknown	Oct 25, 2021
`0.11.9` unknown	Oct 21, 2021
`0.11.8` unknown	Oct 07, 2021
`0.11.7` unknown	Sep 28, 2021
`0.11.6` unknown	Sep 16, 2021
`0.11.5` unknown yanked 2 CVEs	Jul 08, 2021
`0.11.4` unknown yanked 2 CVEs	May 21, 2021
`0.11.3` unknown yanked 2 CVEs	May 20, 2021
`0.11.2` unknown yanked 2 CVEs	May 19, 2021
`0.11.1` unknown yanked 2 CVEs	Apr 22, 2021
`0.11.0` unknown yanked 2 CVEs	Apr 08, 2021
`0.10.2` unknown yanked 2 CVEs	Feb 19, 2021
`0.10.1` unknown yanked 2 CVEs	Feb 12, 2021
`0.9.4` unknown yanked 2 CVEs	Jan 20, 2021
`0.9.2` unknown yanked 2 CVEs	Nov 30, 2020
`0.9.1` unknown yanked 2 CVEs	Oct 30, 2020
`0.9.0` unknown yanked 2 CVEs	Oct 16, 2020
`0.8.1` unknown yanked 2 CVEs	May 08, 2020
`0.8.0` unknown yanked 2 CVEs	May 05, 2020
`0.8.0-rc.0` unknown yanked 2 CVEs	Apr 28, 2020
`0.7.7` unknown yanked 2 CVEs	Mar 07, 2020
`0.7.6` unknown yanked 2 CVEs	Feb 26, 2020
`0.7.5` unknown yanked 2 CVEs	Feb 26, 2020
`0.7.4` unknown yanked 2 CVEs	Feb 26, 2020
`0.7.3` unknown yanked 2 CVEs	Feb 24, 2020
`0.7.2` unknown 1 CVE	Feb 22, 2020
`0.7.1` unknown	Feb 22, 2020
`0.7.0` unknown	Feb 22, 2020

0.13.0-rc.33 unknown

Oct 23, 2024

0.13.0-rc.30 unknown

Oct 22, 2024

0.13.0-rc.18 unknown

Apr 10, 2024

0.13.0-rc.11 unknown

Dec 21, 2022

0.13.0-rc.10 unknown

Dec 02, 2022

0.13.0-rc.9 unknown

Nov 11, 2022

0.13.0-rc.8 unknown

Nov 09, 2022

0.13.0-rc.6 unknown

Oct 20, 2022

0.13.0-rc.5 unknown

Oct 05, 2022

0.13.0-rc.4 unknown

Sep 29, 2022

0.13.0-rc.3 unknown

Sep 16, 2022

0.13.0-rc.2 unknown

Sep 02, 2022

0.13.0-rc.1 unknown

Aug 19, 2022

0.12.4 unknown

Jun 24, 2022

0.12.3 unknown

Jun 17, 2022

0.12.2 unknown

Jun 15, 2022

0.12.1 unknown

Jun 01, 2022

0.12.0 unknown

May 25, 2022

0.12.0-rc.9 unknown

May 19, 2022

0.12.0-rc.8 unknown

May 13, 2022

0.11.10 unknown

Oct 25, 2021

0.11.9 unknown

Oct 21, 2021

0.11.8 unknown

Oct 07, 2021

0.11.7 unknown

Sep 28, 2021

0.11.6 unknown

Sep 16, 2021

0.11.5 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Jul 08, 2021

0.11.4 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

May 21, 2021

0.11.3 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

May 20, 2021

0.11.2 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

May 19, 2021

0.11.1 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 22, 2021

0.11.0 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 08, 2021

0.10.2 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 19, 2021

0.10.1 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 12, 2021

0.9.4 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Jan 20, 2021

0.9.2 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Nov 30, 2020

0.9.1 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Oct 30, 2020

0.9.0 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Oct 16, 2020

0.8.1 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

May 08, 2020

0.8.0 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

May 05, 2020

0.8.0-rc.0 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Apr 28, 2020

0.7.7 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Mar 07, 2020

0.7.6 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 26, 2020

0.7.5 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 26, 2020

0.7.4 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 26, 2020

0.7.3 unknown yanked

2 CVEs

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2021-39228 GHSA-mc22-5q92-8v85 Sep 20, 2021

Memory Safety Issue when using patch or merge on state and assign the result back to state

6.5 / 10

Medium

Network Low None None Unchanged Low Low None

Impact

This vulnerability is a memory safety Issue when using patch or merge on state and assign the result back to state. In this case affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the state, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct.

Details

If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it does not matter what it references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct, which underpins all event data in tremor-script, is representing strings as borrowed beef::Cow<'lifetime, str>, that reference the raw data Vec<u8> the event is based upon. We keep this raw byte-array next to the Value structure inside our Event as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patch event data or static data. When state was introduced to tremor-script (in version 0.7.3) a new possibility to keep Value data around for longer than the lifetime of an event emerged. If event data is merged or patched into state without cloning it first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Patches

The issue has been patched in https://crates.io/crates/tremor-script/0.11.6 and https://github.com/tremor-rs/tremor-runtime/releases/tag/v0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Workarounds

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

References

The actual fix is applied in this PR: https://github.com/tremor-rs/tremor-runtime/pull/1217

For more information

If you have any questions or comments about this advisory:

Open an issue on our repository tremor-rs/tremor-runtime
Please join our discord https://chat.tremor.rs and reach out to the team.

Fixed in


          0.11.6

References

Updated Jul 08, 2026 · Source: OSV.dev

Feb 24, 2020

0.7.2 unknown

1 CVE

CVE-2021-45701 GHSA-3pp4-64mp-9cg9 CVE-2021-45702 GHSA-9qvw-46gf-4fv8 GHSA-q2x5-6q7q-r872 RUSTSEC-2021-0111 Jun 17, 2022

Memory Safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`

High

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two tremor-script language constructs:

A Merge where we assign the result back to the target expression and the expression to be merged needs to reference the event:

let state = merge state of event end;

A Patch where we assign the result back to the target expression and the patch operations used need to reference the event:

let state = patch state of insert event.key => event.value end;

For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it.

Our Value struct which underpins all event data in tremor-script, is representing as borrowed strings beef::Cow<'lifetime, str> that reference the actual Vec<u8> the event is based upon. We keep the raw byte-array next to the event structure inside our Event struct as a self-referential struct, so we make sure that the structured Value and its references are valid across its whole lifetime.

The optimization was considered safe as long as it was only possible to merge or patche event data or static data. When state was introduced to tremor-script a new possibility existed, to keep Value data around for longer than the lifetime of an event. If event data is merged or patched into state without cloning state first, it can still reference keys or values from the previous event, which will now be invalid. This allows access to those already freed regions of memory and to get their content out over the wire.

Workaround

If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to state:

let tmp = merge state of event end;
let state = tmp

Fix

The flaw was corrected in tremor-script version 0.11.6 via commit 1a2efcd by removing the optimization and always clone the target expression of a Merge or [Patch](https://www.tremor.rs/docs/tremor-script/index#patch.

Fixed in


          0.11.6

References

Updated Nov 08, 2023 · Source: OSV.dev

Feb 22, 2020

0.7.1 unknown

Feb 22, 2020

0.7.0 unknown

Feb 22, 2020

Activity

Details