This should be included in next release 1.4.1. However I would recommend you to open ticket with Cisco Small Business Support team which will attach your case to this bug and if there is any beta firmware you can also test it:
Please see attachment to see if that can help on the case, and some routing issues and solutions are also explained.
 change vlan 33 attached to SG500 to new vlan (vlan 34)
 SG500 as DHCP server for vlan 34
 DHCP ACL filter for vlan 33 on SG500
 add a L2 switch between router & SG500
 use ACL to filter DHCP for vlan 33 in SG500
 migrate all vlan 33 from SG500 to the new L2 switch
 both router and SG500 as DHCP server for vlan 33
 SG500 use DHCP host pool for vlan 33 to prevent any allocation
Ip dhcp server
Ip dhcp pool host 33
Add 192.168.33.1 /24 hardware 0000.0000.0001 // MAC of router
//this add will never be assigned since it’s already used by router
I have noticed this same issue on our SG500-52. Though the NAKs don't seem to be affecting anything (well, maybe one embedded device on the network...), it still concerns me that the switch is doing this. And it might in the future cause issues depending on the timing of the NAKs versus the proper DHCP server's response.
I tried creating an ACL for the VLAN (and also to a port) to which the IPV4 interface causing issues is bound, blocking UDP from the switch's source IP on source port 67, dest port 68. But the ACL is not blocking the packets for some reason.
Any timeframe on when 1.4.1 will be released with the fix? Should I open a ticket?
 ACL has no effect on packet from the device itself.
 It is better to use single DHCP server for all subnets other than separate ones for different subnets, since the latter has more administrative overhead.
 Before the fix in next release under plan, alternative solution is to create a single martian DHCP host pool (an unused host IP of the subnet that binds to a non-existent MAC in the network), which will never be assigned to any host, for the SVI subnet that has another DHCP server.