PR:
https://github.com/vyos/vyos-build/pull/1103

There is a straightforward solution here, which requires adjusting the image flavor build tools to respect the changes of https://vyos.dev/T6006, which resolved long-standing issues of migration and config initialization.
In short, after T6006:

• the file /usr/share/vyos/config.boot.defult is the build-time source of truth --- the flavor build system should install any flavor-defined config.boot.default at that location
• both /opt/vyatta/etc/config.boot.default and /opt/vyatta/etc/config/config.boot are installed on first boot, at different stages of gathering system-specific information in vyos-router (component version information, respectively, migration and activation updates)

@AnNK6 thank you for the report and details. The fact is that until privilege separation is implemented (https://vyos.dev/T7583), authentication allows sudo privileges implicitly (via the config system) if not explicitly. In that sense the issue is mooted until the work on the op-mode runner and related is complete, but be assured that alongside the work in T7583 and related, a general audit of shell escape mechanisms is ongoing in preparation; your report is quite useful for that current work. That being said, my quick test of the above against a local KVM system gives a different result (below), so I will need to take a closer look to reproduce.

Note that for 1.4.x there may be a separate cause of the false positive due to the older migration system (revised in 1.5); this is under investigation.

Note that this was fixed in https://vyos.dev/T7319 and backported for inclusion in 1.4.4. However, it will necessarily only apply to any upgrades from that version forward, e.g. 1.4.4 -> 1.4.5

PR:
https://github.com/vyos/vyos1x-config/pull/64

This is due to a hardcoded limit on the size of the underlying unionfs file in vyatta-cfg: as the value was set rather arbitrarily, we will increase the limit from 2^18 to 2^20. Note that limit is encountered irrespective of the use of the http api.

A related issue is here: https://vyos.dev/T8000.

PR:
https://github.com/vyos/vyos-1x/pull/4849

Based on the comments above, I am moving this to 'wishlist' for consideration after the legacy backend is retired. My expectation is that we will not want to drop the invariant as such, however, we will be in a position to consider refinements of the model, radical or conservative, once freed from the legacy constraints.