[Phinix]

OK, so I managed to track down this specific case, and (HOPEFULLY) it will help others to eliminate this from their addons as well.

It appears to be a change in the way ZOS is handling hooks to certain global functions. For example in Master Recipe List, I narrowed the above errors down to two specific hooks. By changing these to use ZO_PreHook() I was able to keep the functionality of the hook and avoid these insecure code errors. So:

	local ESOMRL_ZO_TreeHeader_OnMouseUp = ZO_TreeHeader_OnMouseUp
	ZO_TreeHeader_OnMouseUp = function(self, upInside)
		if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
			local treeNode = self.node.tree
			if treeNode.exclusive or treeNode.open then
				treeNode.exclusive = false
				treeNode.open = false
			end
			stationNav = 1
			stationItem = 1
			ClearStationSelection()
		end
		ESOMRL_ZO_TreeHeader_OnMouseUp(self, upInside)
	end

Becomes:

	ZO_PreHook("ZO_TreeHeader_OnMouseUp",
	function(self, upInside)
		if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
			local treeNode = self.node.tree
			if treeNode.exclusive or treeNode.open then
				treeNode.exclusive = false
				treeNode.open = false
			end
			stationNav = 1
			stationItem = 1
			ClearStationSelection()
		end
	end)

...and:

	local ESOMRL_ZO_TreeSetNodeOpen = ZO_Tree.SetNodeOpen
	ZO_Tree.SetNodeOpen = function(self, treeNode, open, userRequested)
		if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
			if stationNode == 0 then open = false stationNode = 1 end
			if stationItem == 0 or stationNav == 0 then open = false end
		end
		ESOMRL_ZO_TreeSetNodeOpen(self, treeNode, open, userRequested)
	end

Becomes:

	ZO_PreHook(ZO_Tree, "SetNodeOpen",
	function(self, treeNode, open, userRequested)
		if GetCraftingInteractionType() == CRAFTING_TYPE_PROVISIONING then
			if stationNode == 0 then open = false stationNode = 1 end
			if stationItem == 0 or stationNav == 0 then open = false end
		end
	end)

YMMV but at least it a clue.

EDIT:

So the obvious question for Master Chip (or anyone more knowledgeable) would be, WHY?

If I had to guess it would be the way internal references are cleared out from the active context, and it not happening with custom hooks because of some "waiting for return" type state, and some other, newer function that requires code states be "unburdened" by such waiting states in order to be considered "secure."

/stabdark