You do have a few options but they all have their tradeoffs.
First off, you could use a structure instead of a UObject. This would make it easy to copy that data from the weapon on pickup and to configure it from the weapon blueprint. The downside is that copying that structure could become a problem due to size/properties that it stores.
Next option would be that you could use the Instanced object functionality to do what you want, it would allow you to have a UObject*, you’d select a type (from the subtypes of whatever type the property was) and you’d be able to modify the data. The problem here is that you can’t just copy the pointer to that object around because it’s owned by the blueprint and if it’s ever unloaded you lose your object. So for safety you’d have to copy it anyway, but there are at least some functions you can use to do that.
Structurally I think you have a common problem which is mixing config time & runtime data. On the one hand you have values like magazine size, rate of fire and all the effects and on the other you have things like ‘current magazine’ and ‘currently full auto’. The first type of data is stuff you’d only want to set from the editor and you would want to be consistent across all instances of a certain type of weapon pickup (all AK-47’s or all Peacemakers), while the other is the data specific to one gun (this AK-47 vs that AK-47).
Typically, you’d have a class derived from UDataAsset that you configure with all the config stuff. Then the runtime stuff could be a simple structure that is easy to copy between the places you want to track it. You would either pair with (or include in) the structure a pointer to your data asset. The asset with all the config stuff would then be independent of the blueprint and stay loaded as long as you have the type of weapon, even if the pickup actor goes away.